From mailnull@www1.ietf.org Tue Mar 4 07:05:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13725 for ; Tue, 4 Mar 2003 07:05:39 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h24CG6D30291 for sip-archive@odin.ietf.org; Tue, 4 Mar 2003 07:16:06 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24CCSp30089; Tue, 4 Mar 2003 07:12:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24CAHp30028 for ; Tue, 4 Mar 2003 07:10:17 -0500 Received: from alaska.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13597; Tue, 4 Mar 2003 06:59:19 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by alaska.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h24C1HpX006559; Tue, 4 Mar 2003 13:01:18 +0100 (MET) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id F5XHKGWX; Tue, 4 Mar 2003 13:01:17 +0100 Received: from lmf.ericsson.se (EF5DM00K04BAV71.lmf.ericsson.se [131.160.30.19]) by hendrix.lmf.ericsson.se (8.12.6/8.12.6/lmf-2.1-jcs) with ESMTP id h24C1GGh026659; Tue, 4 Mar 2003 14:01:16 +0200 (EET) Message-ID: <3E64958A.9341D652@lmf.ericsson.se> Date: Tue, 04 Mar 2003 14:01:14 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Gonzalo Camarillo X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: sip , sipping CC: Jon Peterson , Dean Willis , Rohan Mahy Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Agenda requests for SF Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Folks, we are going to start gathering agenda requests for the next IETF meeting in San Francisco. Please, let the chairs know if you would like to request a slot. 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 mailnull@www1.ietf.org Tue Mar 4 07:35:45 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15521 for ; Tue, 4 Mar 2003 07:35:45 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h24CkCs32469 for sip-archive@odin.ietf.org; Tue, 4 Mar 2003 07:46:12 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24Cjlp32446; Tue, 4 Mar 2003 07:45:47 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24Celp31994 for ; Tue, 4 Mar 2003 07:40:47 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14980; Tue, 4 Mar 2003 07:29:50 -0500 (EST) Message-Id: <200303041229.HAA14980@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 04 Mar 2003 07:29:49 -0500 Subject: [Sip] I-D ACTION:draft-ietf-sip-content-indirect-mech-02.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : A Mechanism for Content Indirection in Session Initiation Protocol (SIP) Messages Author(s) : S. Olson Filename : draft-ietf-sip-content-indirect-mech-02.txt Pages : 15 Date : 2003-3-3 This document proposes an extension to the URL MIME External- Body Access-Type to satisfy the content indirection requirements for SIP. These extensions are aimed at allowing any MIME part in a SIP message to be referred to indirectly via a URI. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-content-indirect-mech-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-content-indirect-mech-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-content-indirect-mech-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-3-3145049.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-content-indirect-mech-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-content-indirect-mech-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-3145049.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Tue Mar 4 09:14:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22706 for ; Tue, 4 Mar 2003 09:14:25 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h24EOtQ07605 for sip-archive@odin.ietf.org; Tue, 4 Mar 2003 09:24:55 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24EORp07587; Tue, 4 Mar 2003 09:24:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24AHZp22406 for ; Tue, 4 Mar 2003 05:17:35 -0500 Received: from idefix.ict.tuwien.ac.at (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11054 for ; Tue, 4 Mar 2003 05:06:39 -0500 (EST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 4 Mar 2003 11:08:28 +0100 Message-ID: <1FE28144CBED9F4C8959A2D25CDDF02706D1E3@idefix.ict.tuwien.ac.at> X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Topic: Event Notifications with Multicast Thread-Index: AcLiNf/1SOhPVnGxS1u5R/NWENcDuA== From: "Klaus Darilion" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h24AHZp22407 Subject: [Sip] Event Notifications with Multicast Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hello! Is it possible to use multicast for sending NOTIFY requests to the subscribers? I want to send the notifications very fast and it takes some time to do the sending one after another. Regards, Klaus Darilion _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Tue Mar 4 10:40:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27555 for ; Tue, 4 Mar 2003 10:40:31 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h24Fp2P14589 for sip-archive@odin.ietf.org; Tue, 4 Mar 2003 10:51:02 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24Foep14565; Tue, 4 Mar 2003 10:50:40 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24Fo0p14477 for ; Tue, 4 Mar 2003 10:50:00 -0500 Received: from mail.cit.ie (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27504; Tue, 4 Mar 2003 10:38:57 -0500 (EST) Received: from EEB174W2Kvk (unverified [157.190.81.172]) by cit.ie (Rockliffe SMTPRA 5.2.5) with SMTP id ; Tue, 4 Mar 2003 15:28:00 +0000 Reply-To: From: "Valerie Kenneally" To: , Cc: , , , , Date: Tue, 4 Mar 2003 15:41:07 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Subject: [Sip] Question on Basic Call flows document section 3.6 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi All, In document at the below link http://www.ietf.org/internet-drafts/draft-ietf-sipping-basic-call-flows-01.t xt section 3.6 "Session via Redirect and Proxy Servers with the SDP in ACK". I am wondering if someone can explain to me how the INVITE (F4) is directed from User A to Proxy 3 without any Route header being included in the message. I have been trying to figure this out for a while and I'd really appreciate any feedback asap Thanks in advance, Val ------------------------ Val Kenneally, Post-Graduate, Electronic Eng. Dept., CIT, Rossa Ave., Bishopstown, Cork, Ireland. ------------------------ Tel: +353 87 2273668 Fax: +353 21 4326625 -------------------Legal Disclaimer--------------------------------------- The above electronic mail transmission is confidential and intended only for the person to whom it is addressed. Its contents may be protected by legal and/or professional privilege. Should it be received by you in error please contact the sender at the above quoted email address. Any unauthorised form of reproduction of this message is strictly prohibited. The Institute does not guarantee the security of any information electronically transmitted and is not liable if the information contained in this communication is not a proper and complete record of the message as transmitted by the sender nor for any delay in its receipt. ---------------------------------------------------------------------------------------- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Tue Mar 4 14:27:24 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06468 for ; Tue, 4 Mar 2003 14:27:24 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h24Jc0w07178 for sip-archive@odin.ietf.org; Tue, 4 Mar 2003 14:38:00 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24JbS507017; Tue, 4 Mar 2003 14:37:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24JYn506267 for ; Tue, 4 Mar 2003 14:34:49 -0500 Received: from web41508.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA06387 for ; Tue, 4 Mar 2003 14:23:41 -0500 (EST) Message-ID: <20030304192543.29760.qmail@web41508.mail.yahoo.com> Received: from [131.107.3.84] by web41508.mail.yahoo.com via HTTP; Tue, 04 Mar 2003 11:25:43 PST Date: Tue, 4 Mar 2003 11:25:43 -0800 (PST) From: Sean Olson Subject: Re: [Sip] Event Notifications with Multicast To: Klaus Darilion , sip@ietf.org In-Reply-To: <1FE28144CBED9F4C8959A2D25CDDF02706D1E3@idefix.ict.tuwien.ac.at> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Intriguing idea, but it has some issues. Namely, what would you put in the From and Call-ID for such a NOTIFY request that was destined to multiple subscribers (who had issued SUBSCRIBE requests with different From and Call-ID values) Note that there is no inherent reason you could not send these NOTIFY requests in parallel. That is more of an implementation issue than a protocol one. Regards, Sean Olson Microsoft --- Klaus Darilion wrote: > Hello! > > Is it possible to use multicast for sending NOTIFY > requests to the > subscribers? I want to send the notifications very > fast and it takes > some time to do the sending one after another. > > Regards, > Klaus Darilion > _______________________________________________ > Sip mailing list > https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP > Protocol > Use sip-implementors@cs.columbia.edu for questions > on current sip > Use sipping@ietf.org for new developments on the > application of sip __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Tue Mar 4 18:34:17 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15349 for ; Tue, 4 Mar 2003 18:34:16 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h24Nix824540 for sip-archive@odin.ietf.org; Tue, 4 Mar 2003 18:44:59 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24Ni5524493; Tue, 4 Mar 2003 18:44:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24NgM524447 for ; Tue, 4 Mar 2003 18:42:22 -0500 Received: from fox.iptel.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15269 for ; Tue, 4 Mar 2003 18:31:09 -0500 (EST) Received: from localhost (jiri@localhost) by fox.iptel.org (8.11.6/8.11.6) with ESMTP id h24NX6n26205; Wed, 5 Mar 2003 00:33:06 +0100 Date: Wed, 5 Mar 2003 00:33:06 +0100 (CET) From: Jiri Kuthan To: cc: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Sip] manyfolks comment Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , I think it would be useful to mention the special-case of forking in the manyfolks draft. I think it is not entirely obvious and readers would be certainly pleased if the document included a how-to on that. imho, it takes initiating a PRACK transaction (and assuring preconditions) to each destination which replied with 18x. I'm not yet sure, what CSeq to set for all the PRACKs. Obviously, all UASs deserve CSeq(invite)+1 but the idea of sending multiple "parallel" transactions with the same CSeq is still surprising to me. Comments? Thanks, -Jiri _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Tue Mar 4 18:51:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15861 for ; Tue, 4 Mar 2003 18:51:04 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2501l625462 for sip-archive@odin.ietf.org; Tue, 4 Mar 2003 19:01:47 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2500G525347; Tue, 4 Mar 2003 19:00:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24Nxe525286 for ; Tue, 4 Mar 2003 18:59:40 -0500 Received: from gamma.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15805; Tue, 4 Mar 2003 18:48:25 -0500 (EST) Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h24NoSZ13242; Tue, 4 Mar 2003 15:50:28 -0800 (PST) Message-Id: <200303042350.h24NoSZ13242@gamma.isi.edu> To: IETF-Announce: ; Cc: rfc-editor@rfc-editor.org, sipping@ietf.org, sip@ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Tue, 04 Mar 2003 15:50:28 -0800 Subject: [Sip] RFC 3485 on The Session Initiation Protocol (SIP) and Session Description Protocol (SDP) Static Dictionary for Signaling Compression (SigComp) Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3485 Title: The Session Initiation Protocol (SIP) and Session Description Protocol (SDP) Static Dictionary for Signaling Compression (SigComp) Author(s): M. Garcia-Martin, C. Bormann, J. Ott, R. Price, A. B. Roach Status: Standards Track Date: February 2003 Mailbox: miguel.a.garcia@ericsson.com, cabo@tzi.org, jo@tzi.org, richard.price@roke.co.uk, adam@dynamicsoft.com Pages: 30 Characters: 80195 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-sipping-sigcomp-sip-dictionary-05.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3485.txt The Session Initiation Protocol (SIP) is a text-based protocol for initiating and managing communication sessions. The protocol can be compressed by using Signaling Compression (SigComp). Similarly, the Session Description Protocol (SDP) is a text-based protocol intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. This memo defines the SIP/SDP-specific static dictionary that SigComp may use in order to achieve higher efficiency. The dictionary is compression algorithm independent. This document is a product of the Session Initiation Proposal Investigation Working Group and the Session Initiation Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <030304154731.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3485 --OtherAccess Content-Type: Message/External-body; name="rfc3485.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <030304154731.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Wed Mar 5 04:05:58 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22204 for ; Wed, 5 Mar 2003 04:05:58 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h259GpG07000 for sip-archive@odin.ietf.org; Wed, 5 Mar 2003 04:16:51 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h259FO506930; Wed, 5 Mar 2003 04:15:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h259De506868 for ; Wed, 5 Mar 2003 04:13:40 -0500 Received: from condor.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22156 for ; Wed, 5 Mar 2003 04:02:15 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by condor.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2594IW1027959; Wed, 5 Mar 2003 10:04:18 +0100 (MET) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id F5XHR30Z; Wed, 5 Mar 2003 10:04:17 +0100 Received: from lmf.ericsson.se (EF5DM00K04BAV71.lmf.ericsson.se [131.160.30.19]) by hendrix.lmf.ericsson.se (8.12.6/8.12.6/lmf-2.1-jcs) with ESMTP id h2594HEn029000; Wed, 5 Mar 2003 11:04:17 +0200 (EET) Message-ID: <3E65BD90.787F72C8@lmf.ericsson.se> Date: Wed, 05 Mar 2003 11:04:16 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Gonzalo Camarillo X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jiri Kuthan CC: sip@ietf.org References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Re: manyfolks comment Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Jiri, > imho, it takes initiating a PRACK transaction (and assuring preconditions) > to each destination which replied with 18x. Yes, if you want to use preconditions, this is what you will most likely do (assuming that you can reserve so much resources). > I'm not yet sure, what CSeq to set for all the PRACKs. Obviously, all UASs > deserve CSeq(invite)+1 but the idea of sending multiple "parallel" transactions > with the same CSeq is still surprising to me. The Cseq number spaces of different dialogs are independent. Even if all the dialogs share the same Call-ID, they are still independent. Therefore, there is nothing weird in sending the same Cseq to different destinations. If, in the future, we review the manyfolks spec, it may be worthwhile mentioning that forking can interact with manyfolks... although I do not see any big technical issue there. Thanks for the comments, Gonzalo _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Wed Mar 5 04:54:03 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23158 for ; Wed, 5 Mar 2003 04:54:03 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h25A4vh09714 for sip-archive@odin.ietf.org; Wed, 5 Mar 2003 05:04:57 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25A4Z509697; Wed, 5 Mar 2003 05:04:35 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25A3Z509641 for ; Wed, 5 Mar 2003 05:03:35 -0500 Received: from fox.iptel.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23111 for ; Wed, 5 Mar 2003 04:52:09 -0500 (EST) Received: from jku07.iptel.org (port-212-202-200-46.reverse.qdsl-home.de [212.202.200.46]) by fox.iptel.org (8.11.6/8.11.6) with ESMTP id h259s9J14796; Wed, 5 Mar 2003 10:54:10 +0100 Message-Id: <5.2.0.9.0.20030305102221.015f8da8@iptel.org> X-Sender: jiri@iptel.org (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 05 Mar 2003 10:23:07 +0100 To: Gonzalo Camarillo From: Jiri Kuthan Cc: sip@ietf.org In-Reply-To: <3E65BD90.787F72C8@lmf.ericsson.se> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [Sip] Re: manyfolks comment Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , At 10:04 AM 3/5/2003, Gonzalo Camarillo wrote: >If, in the future, we review the manyfolks spec, it may be worthwhile >mentioning that forking can interact with manyfolks... although I do not >see any big technical issue there. I agree -- it just did not seem so intuitively understandable and thus worth mentioning to me. -Jiri _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Wed Mar 5 13:59:46 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21880 for ; Wed, 5 Mar 2003 13:59:46 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h25JAQx09224 for sip-archive@odin.ietf.org; Wed, 5 Mar 2003 14:10:26 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25J9bO09162; Wed, 5 Mar 2003 14:09:37 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25Amm513016 for ; Wed, 5 Mar 2003 05:48:48 -0500 Received: from idefix.ict.tuwien.ac.at (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24323 for ; Wed, 5 Mar 2003 05:37:21 -0500 (EST) content-class: urn:content-classes:message Subject: RE: [Sip] Event Notifications with Multicast MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 5 Mar 2003 11:39:17 +0100 Message-ID: <1FE28144CBED9F4C8959A2D25CDDF02706D1F4@idefix.ict.tuwien.ac.at> X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Topic: [Sip] Event Notifications with Multicast Thread-Index: AcLig+HM5zbKuGMsQWKieweNivRrpgAds/lg From: "Klaus Darilion" To: "Sean Olson" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h25Amm513017 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit I know that won't an easy solution. My first idea was to use unicast for the subscription request, the subscription respond and the notification respond, and multicast only for the NOTIFY request. In the subscription response, the notifiyer has to tell the subscriber which multicast address it should bind to. The From: headers in the SUBSCRIBE request need not to be changed. The To: header can have some generic name like "subscriber@multicast-IP-address". The Call-ID will probably be different as the one in the subscription. So, subscribers has to use the Call-ID they receive in the first notification (I think this is similar to subscriptions without a SUBSCRIBE transaction). I found 2 solutions to differentiate the responses: Either the subscriber rewrites the To: header to its own sip address or the subscriber inserts an header with its sip-uri. NOTIFY retransmission should be sent by unicast to avoid annoying of the subscribers which had responded to the notification. I had the idea while I analyzed the presence capability of KPhone. KPhone (respectively dissipate) takes 2ms to send a notification (1GHz PC), but I want to notify a lot of subscribers (50 ore more) within a very short time (~20ms). So I thought of multicast. (I know, another way would be to use a faster SIP stack.) Regards, Klaus Darilion > -----Original Message----- > From: Sean Olson [mailto:seancolson@yahoo.com] > Sent: Tuesday, March 04, 2003 8:26 PM > To: Klaus Darilion; sip@ietf.org > Subject: Re: [Sip] Event Notifications with Multicast > > > Intriguing idea, but it has some issues. Namely, > what would you put in the From and Call-ID > for such a NOTIFY request that was destined to > multiple subscribers (who had issued SUBSCRIBE > requests with different From and Call-ID values) > > Note that there is no inherent reason you could > not send these NOTIFY requests in parallel. That > is more of an implementation issue than a protocol > one. > > Regards, > Sean Olson > Microsoft > > > --- Klaus Darilion wrote: > > Hello! > > > > Is it possible to use multicast for sending NOTIFY > > requests to the > > subscribers? I want to send the notifications very > > fast and it takes > > some time to do the sending one after another. > > > > Regards, > > Klaus Darilion _______________________________________________ > > Sip mailing list > > https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP > > Protocol > > Use sip-implementors@cs.columbia.edu for questions > > on current sip > > Use sipping@ietf.org for new developments on the > > application of sip > > > __________________________________________________ > Do you Yahoo!? > Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Thu Mar 6 03:58:55 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28783 for ; Thu, 6 Mar 2003 03:58:55 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2699pG15926 for sip-archive@odin.ietf.org; Thu, 6 Mar 2003 04:09:51 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2698tO15881; Thu, 6 Mar 2003 04:08:55 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2697tO15815 for ; Thu, 6 Mar 2003 04:07:55 -0500 Received: from hotgroup.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28746 for ; Thu, 6 Mar 2003 03:56:23 -0500 (EST) Message-Id: <200303060856.DAA28746@ietf.org> Received: from chenjian ([218.88.35.61]) by hotgroup.org ([127.0.0.1]) with SMTP (MDaemon.PRO.v6.0.7.R) for ; Thu, 06 Mar 2003 17:02:14 +0800 From: "paopai" To: "sip@ietf.org" X-mailer: Foxmail 4.2 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="GB2312" Date: Thu, 6 Mar 2003 16:59:1 +0800 X-Authenticated-Sender: swifthorse@hotgroup.org X-MDRemoteIP: 218.88.35.61 X-Return-Path: swifthorse@hotgroup.org X-MDaemon-Deliver-To: sip@ietf.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2697uO15816 Subject: [Sip] (no subject) Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit sip£¬ÄúºÃ£¡ ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡Ö Àñ£¡ ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡paopai ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡swifthorse@hotgroup.org ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡2003-03-06 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Fri Mar 7 07:12:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24041 for ; Fri, 7 Mar 2003 07:12:36 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h27CO5R17998 for sip-archive@odin.ietf.org; Fri, 7 Mar 2003 07:24:05 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27CN5O17929; Fri, 7 Mar 2003 07:23:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27C6fO15814 for ; Fri, 7 Mar 2003 07:06:42 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21633; Fri, 7 Mar 2003 06:54:42 -0500 (EST) Message-Id: <200303071154.GAA21633@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 07 Mar 2003 06:54:42 -0500 Subject: [Sip] I-D ACTION:draft-ietf-sip-mib-05.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : Management Information Base for Session Initiation Protocol Author(s) : K. Lingle, J. Maeng, J. Mule, D. Walker Filename : draft-ietf-sip-mib-05.txt Pages : 97 Date : 2003-3-6 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes a set of managed objects that are used to manage Session Initiation Protocol (SIP) entities, which include User Agents, Proxy servers, Redirect servers and Registrars. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-mib-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-mib-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-mib-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: <2003-3-6125500.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-mib-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-mib-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-6125500.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Fri Mar 7 07:39:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26883 for ; Fri, 7 Mar 2003 07:39:40 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h27CpAQ21210 for sip-archive@odin.ietf.org; Fri, 7 Mar 2003 07:51:10 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27CoTO21132; Fri, 7 Mar 2003 07:50:29 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27Cn3O21019 for ; Fri, 7 Mar 2003 07:49:03 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26664 for ; Fri, 7 Mar 2003 07:37:01 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by albatross.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h27Cd4B3007145; Fri, 7 Mar 2003 13:39:04 +0100 (MET) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id FD4JRW05; Fri, 7 Mar 2003 13:39:04 +0100 Received: from lmf.ericsson.se (EF5DM00K04BAV71.lmf.ericsson.se [131.160.30.19]) by hendrix.lmf.ericsson.se (8.12.8/8.12.8/lmf-2.1-jcs) with ESMTP id h27Cd4lW016612; Fri, 7 Mar 2003 14:39:04 +0200 (EET) Message-ID: <3E6892E5.8E82856C@lmf.ericsson.se> Date: Fri, 07 Mar 2003 14:39:01 +0200 X-Sybari-Trust: 2811b654 9ffcebbb 7a95d2f4 00000138 From: Gonzalo Camarillo X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Robert Sparks CC: sip@ietf.org Subject: Re: [Sip] I-D ACTION:draft-sparks-sip-noninvite-00.txt References: <200302111144.GAA28328@ietf.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Robert, a couple of comments on the draft. At the end of Section 5.1, you say that SUBSCRIBE "proofs that another option exists". However, SUBSCRIBE/NOTIFY does not resolve the HERP problem (e.g., one of the UASs wants to challenge the request and the other does not). In Section 6, you mention: "ACK is not needed for this pending non-INVITE because we have removed unreliable transports. (ACK was originally needed for INVITE because reliability over UDP became the server's responsibility after its first response and the server needed to know when to stop retransmitting." Reliability was not the only (original) purpose of ACK. If you receive a request and respond immediately, you can assume that the client is still there. However, if you receive a request, take a long time doing whaever processing is needed, and then answer, you want to be sure that the client is still there. The ACK confirms that the client has not died or given up in the meantime. It may be good to document this in the draft. Thanks, Gonzalo Internet-Drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > Title : Considerations for the Session Initiation Protocol's > non-INVITE Transaction > Author(s) : R. Sparks > Filename : draft-sparks-sip-noninvite-00.txt > Pages : 14 > Date : 2003-2-10 > > This draft explores several issues with the Session Initiation > Protocol's non-INVITE transaction. It focuses on the use of > provisional responses and on problems related to transaction > timeouts. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-sparks-sip-noninvite-00.txt > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body of the message. > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-sparks-sip-noninvite-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-sparks-sip-noninvite-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > ------------------------------------------------------------------------ -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland http://www.hut.fi/~gonzalo _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Fri Mar 7 10:05:00 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08248 for ; Fri, 7 Mar 2003 10:05:00 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h27FGXp02277 for sip-archive@odin.ietf.org; Fri, 7 Mar 2003 10:16:33 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27FChO01836; Fri, 7 Mar 2003 10:12:43 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27F4sO00302 for ; Fri, 7 Mar 2003 10:04:54 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07014; Fri, 7 Mar 2003 09:52:50 -0500 (EST) Message-Id: <200303071452.JAA07014@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 07 Mar 2003 09:52:50 -0500 Subject: [Sip] I-D ACTION:draft-ietf-sip-join-01.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , --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 Session Inititation Protocol (SIP) 'Join' Header Author(s) : R. Mahy, D. Petrie Filename : draft-ietf-sip-join-01.txt Pages : 17 Date : 2003-3-6 This document defines a new header for use with SIP multi-party applications and call control. The Join header is used to logically join an existing SIP dialog with a new SIP dialog. This primitive can be used to enable a variety of features, for example: 'Barge-In', answering-machine-style 'Message Screening' and 'Call Center Monitoring'. Note that definition of these example features is non- normative. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-join-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-join-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-join-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-3-6174412.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-join-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-join-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-6174412.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Fri Mar 7 10:05:21 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08301 for ; Fri, 7 Mar 2003 10:05:21 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h27FGtK02347 for sip-archive@odin.ietf.org; Fri, 7 Mar 2003 10:16:55 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27FCFO01773; Fri, 7 Mar 2003 10:12:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27F4GO32712 for ; Fri, 7 Mar 2003 10:04:16 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06883; Fri, 7 Mar 2003 09:52:12 -0500 (EST) Message-Id: <200303071452.JAA06883@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 07 Mar 2003 09:52:11 -0500 Subject: [Sip] I-D ACTION:draft-ietf-sip-replaces-03.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : The Session Inititation Protocol (SIP) 'Replaces' Header Author(s) : B. Biggs, R. Dean, R. Mahy Filename : draft-ietf-sip-replaces-03.txt Pages : 17 Date : 2003-3-6 This document defines a new header for use with SIP multi-party applications and call control. The Replaces header is used to logically replace an existing SIP dialog with a new SIP dialog. This primitive can be used to enable a variety of features, for example: 'Attended Transfer' and 'Retrieve from Call Park'. Note that definition of these example features is non-normative. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-replaces-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-replaces-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-replaces-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-3-6173432.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-replaces-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-replaces-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-6173432.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Fri Mar 7 15:27:47 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27777 for ; Fri, 7 Mar 2003 15:27:47 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h27KdRc05197 for sip-archive@odin.ietf.org; Fri, 7 Mar 2003 15:39:27 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27KcgO04964; Fri, 7 Mar 2003 15:38:42 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27KZiO03955 for ; Fri, 7 Mar 2003 15:35:44 -0500 Received: from bdsl.greycouncil.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27563 for ; Fri, 7 Mar 2003 15:23:32 -0500 (EST) Received: from txdwillis (bdsl.66.12.12.254.gte.net [66.12.12.254]) (authenticated bits=0) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h27KPT49000934 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 7 Mar 2003 14:25:38 -0600 From: "Dean Willis" To: Date: Fri, 7 Mar 2003 14:25:11 -0600 Message-ID: <009f01c2e4e7$ac466cb0$ee036e3f@txdwillis> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Content-Transfer-Encoding: 7bit Subject: [Sip] SIP IETF56 Web Site live and agenda requests posted Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit See http://www.softarmor.com/sipwg/meets/ietf56/requests.html For the list of requested agenda topics so far (and send me anything I'm missing) And of course, general meeting info will be at http://www.softarmor.com/sipwg/meets/ietf56/ Thanks, -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Fri Mar 7 15:42:46 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00494 for ; Fri, 7 Mar 2003 15:42:46 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h27KsQL06518 for sip-archive@odin.ietf.org; Fri, 7 Mar 2003 15:54:26 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27Ks3O06496; Fri, 7 Mar 2003 15:54:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27KovO06070 for ; Fri, 7 Mar 2003 15:50:57 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29918; Fri, 7 Mar 2003 15:38:45 -0500 (EST) Message-Id: <200303072038.PAA29918@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 07 Mar 2003 15:38:45 -0500 Subject: [Sip] I-D ACTION:draft-ietf-sip-authid-body-01.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , --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 : SIP Authenticated Identity Body (AIB) Format Author(s) : J. Peterson Filename : draft-ietf-sip-authid-body-01.txt Pages : 11 Date : 2003-3-7 RFC3261 introduces the concept of adding an S/MIME body to a SIP request or response in order to provide reference integrity over its headers. This document provides a more specific mechanism to derive integrity and authentication properties from an 'authenticated identity body', a digitally-signed SIP message or message fragment. A standard format for such bodies (known as Authenticated Identity Bodies, or AIBs) is given in this document. Some considerations for the processing of AIBs by recipients of SIP messages with such bodies are also given. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-authid-body-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-authid-body-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-authid-body-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-3-7144208.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-authid-body-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-authid-body-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-7144208.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Fri Mar 7 16:00:03 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02609 for ; Fri, 7 Mar 2003 16:00:03 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h27LBiJ09374 for sip-archive@odin.ietf.org; Fri, 7 Mar 2003 16:11:44 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27LB2O09102; Fri, 7 Mar 2003 16:11:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27KodO06034 for ; Fri, 7 Mar 2003 15:50:39 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29873; Fri, 7 Mar 2003 15:38:28 -0500 (EST) Message-Id: <200303072038.PAA29873@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 07 Mar 2003 15:38:28 -0500 Subject: [Sip] I-D ACTION:draft-ietf-sip-callerprefs-08.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : Caller Preferences and Callee Capabilities for the Session Initiation Protocol (SIP) Author(s) : H. Schulzrinne, J. Rosenberg, P. Kyzivat Filename : draft-ietf-sip-callerprefs-08.txt Pages : 58 Date : 2003-3-7 This document describes a set of extensions to the Session Initiation Protocol (SIP) which allow a caller to express preferences about request handling in servers. These preferences include the ability to select which URIs a request gets routed to, and to specify certain request handling directives in proxies and redirect servers. It does so by defining four new request headers, Accept-Contact, Reject- Contact, Require-Contact and Request-Disposition, which specify the caller's preferences. The extension also defines new parameters for the Contact header that describe the capabilities and characteristics of a UA. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-callerprefs-08.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-callerprefs-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-callerprefs-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-3-7151909.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-callerprefs-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-callerprefs-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-7151909.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Fri Mar 7 16:00:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02723 for ; Fri, 7 Mar 2003 16:00:48 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h27LCTD09521 for sip-archive@odin.ietf.org; Fri, 7 Mar 2003 16:12:29 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27LBGO09192; Fri, 7 Mar 2003 16:11:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27KolO06047 for ; Fri, 7 Mar 2003 15:50:47 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29897; Fri, 7 Mar 2003 15:38:36 -0500 (EST) Message-Id: <200303072038.PAA29897@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 07 Mar 2003 15:38:36 -0500 Subject: [Sip] I-D ACTION:draft-ietf-sip-identity-01.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP) Author(s) : J. Peterson Filename : draft-ietf-sip-identity-01.txt Pages : 16 Date : 2003-3-7 The existing mechanisms for expressing identity in the Session Initiation Protocol oftentimes do not permit an administrative domain to verify securely the identity of the originator of a request. This document recommends practices and conventions for authenticating end users, and proposes a way to distribute cryptographically secure authenticated identities within SIP messages. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-identity-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-identity-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-identity-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-3-7151928.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-identity-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-identity-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-7151928.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Mon Mar 10 07:17:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02165 for ; Mon, 10 Mar 2003 07:17:05 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2ACU3H06612 for sip-archive@odin.ietf.org; Mon, 10 Mar 2003 07:30:03 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AC63O04965; Mon, 10 Mar 2003 07:06:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AAiOO32224 for ; Mon, 10 Mar 2003 05:44:24 -0500 Received: from idefix.ict.tuwien.ac.at (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12172 for ; Mon, 10 Mar 2003 05:30:57 -0500 (EST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 10 Mar 2003 11:32:57 +0100 Message-ID: <1FE28144CBED9F4C8959A2D25CDDF02706D22E@idefix.ict.tuwien.ac.at> X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Topic: Push-To-Talk with SIP Thread-Index: AcLm8Gpzm0q0+z4GSfm02npdYLWDfg== From: "Klaus Darilion" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2AAiOO32225 Subject: [Sip] Push-To-Talk with SIP Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hello! Nokia, Siemens and Ericsson have announced that they are developing a push-to-talk application for GSM networks with GPRS and for future 3G networks. They want to use SIP for signaling but I couldn't find any more detailed information. Does someone of you know some details about the PTT signaling with SIP? Do they care about arbitration if two people want to talk to the same group at the same time? Are there some drafts or discussions about this topics? With kind regards, Klaus Darilion _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Mon Mar 10 08:52:27 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19831 for ; Mon, 10 Mar 2003 08:52:27 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2AE5Pa12607 for sip-archive@odin.ietf.org; Mon, 10 Mar 2003 09:05:25 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AE52O12588; Mon, 10 Mar 2003 09:05:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AE3VO12512 for ; Mon, 10 Mar 2003 09:03:31 -0500 Received: from gwsmtp.thomson-csf.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19401 for ; Mon, 10 Mar 2003 08:50:00 -0500 (EST) Received: from thalescan.corp.thales (200.3.2.3) by gwsmtp.thomson-csf.com (NPlex 6.5.026) id 3E64E7BF000B5E3D for sip@ietf.org; Mon, 10 Mar 2003 14:54:21 +0100 Received: from msw001.uk.trt.thales ([192.168.224.28]) by thalescan with InterScan Messaging Security Suite; Mon, 10 Mar 2003 14:51:46 +0100 Received: from NTS013.uk.trt.thales (unverified) by msw001.uk.trt.thales (Content Technologies SMTPRS 4.2.10) with ESMTP id for ; Mon, 10 Mar 2003 13:51:35 +0000 Received: by NTS013.uk.trt.thales with Internet Mail Service (5.5.2656.59) id ; Mon, 10 Mar 2003 13:48:53 -0000 Message-ID: <51BF576D5A02CC4CB2591F50994FD76614E7E6@NTS013.uk.trt.thales> From: "Burnside, Andrew" To: "'sip@ietf.org'" Date: Mon, 10 Mar 2003 13:48:46 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] Inter-domain QoS with SIP Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Hello I am currently looking at options for providing QoS managed inter-domain connections using SIP. This will probably be in a DiffServ architecture, with aggregated flows between domains where possible. Has there been much work done in this area with SIP? I saw that Henry Sinnreich had an Internet Draft out on this topic back in 2000, though I can't find any references to subsequent work. Regards Andrew Burnside _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Mon Mar 10 09:37:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26254 for ; Mon, 10 Mar 2003 09:37:39 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2AEocw16018 for sip-archive@odin.ietf.org; Mon, 10 Mar 2003 09:50:38 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AEoCO16008; Mon, 10 Mar 2003 09:50:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AEnnO15972 for ; Mon, 10 Mar 2003 09:49:49 -0500 Received: from ss8mail1.ss8ott (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26210 for ; Mon, 10 Mar 2003 09:36:17 -0500 (EST) Received: by smtp.ss8.com with Internet Mail Service (5.5.2653.19) id ; Mon, 10 Mar 2003 09:39:23 -0500 Message-ID: <8BAF8B40C4D2D411ADC300508BD63D6902BCBD09@smtp.ss8.com> From: Li Li To: "'sip@ietf.org'" Date: Mon, 10 Mar 2003 09:39:14 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] SIP Privacy draft Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Can anybody help me to understand what happened to the privay draft that had the remote-party-ID header? Is it completely obsoleted? Or is it moved to some other draft? RFC 3323 does not include such header operation mechanism. Thanks, Li Li > -----Original Message----- > From: Burnside, Andrew [mailto:Andrew.Burnside@thalesgroup.com] > Sent: Monday, March 10, 2003 8:49 AM > To: 'sip@ietf.org' > Subject: [Sip] Inter-domain QoS with SIP > > > Hello > > I am currently looking at options for providing QoS managed > inter-domain > connections using SIP. This will probably be in a DiffServ > architecture, > with aggregated flows between domains where possible. Has > there been much > work done in this area with SIP? > > I saw that Henry Sinnreich had an Internet Draft out on this > topic back in > 2000, though I can't find any references to subsequent work. > > Regards > > Andrew Burnside > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Mon Mar 10 09:49:03 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26776 for ; Mon, 10 Mar 2003 09:49:03 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2AF23S16596 for sip-archive@odin.ietf.org; Mon, 10 Mar 2003 10:02:03 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AEffO15571; Mon, 10 Mar 2003 09:41:41 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AEe0O15493 for ; Mon, 10 Mar 2003 09:40:00 -0500 Received: from pmesmtp01.wcom.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25827 for ; Mon, 10 Mar 2003 09:26:29 -0500 (EST) Received: from pmismtp03.wcomnet.com ([166.38.62.38]) by firewall.wcom.com (Iplanet MTA 5.2) with ESMTP id <0HBJ00MFGEONCJ@firewall.wcom.com> for sip@ietf.org; Mon, 10 Mar 2003 14:24:23 +0000 (GMT) Received: from pmismtp03.wcomnet.com by pmismtp03.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0HBJ00301EEMB7@pmismtp03.wcomnet.com>; Mon, 10 Mar 2003 14:24:23 +0000 (GMT) Received: from hsinnreich2 ([166.50.136.112]) by pmismtp03.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0HBJ0037REM6T3@pmismtp03.wcomnet.com>; Mon, 10 Mar 2003 14:22:59 +0000 (GMT) Date: Mon, 10 Mar 2003 08:22:53 -0600 From: Henry Sinnreich Subject: RE: [Sip] Inter-domain QoS with SIP In-reply-to: <51BF576D5A02CC4CB2591F50994FD76614E7E6@NTS013.uk.trt.thales> To: "'Burnside, Andrew'" , sip@ietf.org Message-id: <000c01c2e710$8d001100$708832a6@hsinnreich2> Organization: WorldCom, Inc. MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook, Build 10.0.3416 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Please see for interdomain QOS: http://www.ietf.org/internet-drafts/draft-johnston-sip-osp-token-04.txt It also has the updated interdomain model. Thanks, Henry > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On > Behalf Of Burnside, Andrew > Sent: Monday, March 10, 2003 7:49 AM > To: 'sip@ietf.org' > Subject: [Sip] Inter-domain QoS with SIP > > > Hello > > I am currently looking at options for providing QoS managed > inter-domain connections using SIP. This will probably be in > a DiffServ architecture, with aggregated flows between > domains where possible. Has there been much work done in this > area with SIP? > > I saw that Henry Sinnreich had an Internet Draft out on this > topic back in 2000, though I can't find any references to > subsequent work. > > Regards > > Andrew Burnside > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current > sip Use sipping@ietf.org for new developments on the > application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Mon Mar 10 11:25:34 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01575 for ; Mon, 10 Mar 2003 11:25:34 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2AGcad24892 for sip-archive@odin.ietf.org; Mon, 10 Mar 2003 11:38:36 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AGbqO24853; Mon, 10 Mar 2003 11:37:52 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AGYQO23905 for ; Mon, 10 Mar 2003 11:34:26 -0500 Received: from sj-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01392 for ; Mon, 10 Mar 2003 11:20:52 -0500 (EST) 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.6/8.12.6) with ESMTP id h2AGMq0E018701; Mon, 10 Mar 2003 08:22:53 -0800 (PST) Received: from fluffyw2k (skoehler-w2k1.cisco.com [128.107.142.109]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ACD23389; Mon, 10 Mar 2003 08:22:52 -0800 (PST) From: "Cullen Jennings" To: "'Li Li'" , Subject: RE: [Sip] SIP Privacy draft Date: Mon, 10 Mar 2003 08:22:51 -0800 Message-ID: <006b01c2e721$4c52b160$6d8e6b80@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: <8BAF8B40C4D2D411ADC300508BD63D6902BCBD09@smtp.ss8.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit It became RFC 3325 http://www.ietf.org/rfc/rfc3325.txt > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On > Behalf Of Li Li > Sent: Monday, March 10, 2003 6:39 AM > To: 'sip@ietf.org' > Subject: [Sip] SIP Privacy draft > > > Can anybody help me to understand what happened to the > privay draft that had the remote-party-ID header? Is > it completely obsoleted? Or is it moved to some other > draft? RFC 3323 does not include such header operation > mechanism. > > Thanks, > > Li Li > > > > -----Original Message----- > > From: Burnside, Andrew [mailto:Andrew.Burnside@thalesgroup.com] > > Sent: Monday, March 10, 2003 8:49 AM > > To: 'sip@ietf.org' > > Subject: [Sip] Inter-domain QoS with SIP > > > > > > Hello > > > > I am currently looking at options for providing QoS managed > > inter-domain > > connections using SIP. This will probably be in a DiffServ > > architecture, > > with aggregated flows between domains where possible. Has > > there been much > > work done in this area with SIP? > > > > I saw that Henry Sinnreich had an Internet Draft out on this > > topic back in > > 2000, though I can't find any references to subsequent work. > > > > Regards > > > > Andrew Burnside _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current > sip Use sipping@ietf.org for new developments on the > application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Mon Mar 10 12:36:02 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04857 for ; Mon, 10 Mar 2003 12:36:02 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2AHn7V32000 for sip-archive@odin.ietf.org; Mon, 10 Mar 2003 12:49:07 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AHlvO31904; Mon, 10 Mar 2003 12:47:57 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AHkfO31868 for ; Mon, 10 Mar 2003 12:46:41 -0500 Received: from mail2.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04698 for ; Mon, 10 Mar 2003 12:33:05 -0500 (EST) Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail2.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h2AHX6sH002733; Mon, 10 Mar 2003 12:33:09 -0500 (EST) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 10 Mar 2003 11:35:03 -0600 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A64575@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'Jiri Kuthan'" , sip@ietf.org Cc: Gonzalo.Camarillo@ericsson.com Subject: RE: [Sip] manyfolks comment Date: Mon, 10 Mar 2003 11:35:02 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , > -----Original Message----- > From: Jiri Kuthan [mailto:jiri@iptel.org] > > I'm not yet sure, what CSeq to set for all the PRACKs. > Obviously, all UASs > deserve CSeq(invite)+1 but the idea of sending multiple > "parallel" transactions > with the same CSeq is still surprising to me. Keep in mind: - CSeqs are scoped to dialogs - Dialogs are identified by the set (call-id, local-tag, remote-tag) - 1xx responses from different sources to a forked request will have remote-tags unique to the source /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 mailnull@www1.ietf.org Tue Mar 11 03:52:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13472 for ; Tue, 11 Mar 2003 03:52:39 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2B961D12036 for sip-archive@odin.ietf.org; Tue, 11 Mar 2003 04:06:01 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2B94kO11955; Tue, 11 Mar 2003 04:04:46 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2ACjUO08064 for ; Mon, 10 Mar 2003 07:45:30 -0500 Received: from ietf.org (nsyracus.cnri.reston.va.us [10.27.5.110]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04963 for ; Mon, 10 Mar 2003 07:32:01 -0500 (EST) Message-ID: <3E6C859C.8FEFC7B@ietf.org> Date: Mon, 10 Mar 2003 07:31:24 -0500 From: Natalia Syracuse X-Mailer: Mozilla 4.51 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: sip@ietf.org Content-Type: multipart/mixed; boundary="------------4CF01AB8B5C22B7DB1C66030" Subject: [Sip] draft-khartabil-sip-congestionsafe-ci-02.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. --------------4CF01AB8B5C22B7DB1C66030 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit --------------4CF01AB8B5C22B7DB1C66030 Content-Type: text/plain; charset=iso-8859-1; name="draft-khartabil-sip-congestionsafe-ci-02.txt" Content-Disposition: inline; filename="draft-khartabil-sip-congestionsafe-ci-02.txt" Content-Transfer-Encoding: 8bit SIP H. Khartabil Internet Draft Nokia Expires: Septemper 2, 2003 March 3, 2003 Congestion safety and Content Indirection draft-khartabil-sip-congestionsafe-ci-02.txt STATUS OF THIS MEMO This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts a reference material or to cite them other than as work in progress. The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet Draft will expire on April 23, 2003. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract The Content-Indirection service has many uses. This document describes this service by combining congestion safely and Content- Indirection Mechanism into the one document and presents scenarios where the 2 could be combined. It also introduces extensions to SIP that allows end points to specify their maximum acceptable message size. Khartabil [Page 1] Internet Draft Congestion Safety and C-I October 2002 Table of Contents 1.0 Terminology.......................................................3 2.0 Introduction......................................................3 3.0 Overview of Operation.............................................4 4.0 UA Behaviour......................................................5 4.1 UAC Sending Requests..............................................5 4.2 UAC Behaviour when receiving Response.............................5 4.2.1 ô413ö or ô513ö Error Responses..................................5 4.3 UA Registering Desired Maximum SIP Message Size...................6 4.4 UAS Receiving A SIP Message With Large Contents...................7 4.5 UAS Receiving a Request with Indirected Content...................8 5.0 Proxy Behaviour...................................................8 5.1 Congestion Safe Proxy.............................................8 5.2 Proxy Receiving A SIP Message With Large Content..................8 5.3 Proxy Refusing To Handle Large SIP Requests......................10 5.4 Proxy Performing Content Indirection.............................10 5.5 Proxy Receiving ô413ö Response From Downstream...................11 5.6 Proxy Receiving a Request With Indirected Content................11 6.0 Content Storage Server (CSS) Behaviour...........................12 7.0 Syntax for Extensions............................................12 7.1 Max-Size Header..................................................12 7.2 Max-size parameter...............................................12 8.0 Security considerations..........................................13 9.0 Examples.........................................................13 9.1 UAC Posting Contents to CSS Before Sending SIP MESSAGE...........13 9.2 Receiving A MESSAGE With Large Contents after a REGISTER, Home Proxy Performs Content-Indirection...................................15 9.3 Receiving A NOTIFY With Large Contents, UAS Refuses To Handle Request..............................................................17 10.0 IANA Considerations.............................................19 11.0 Acknowledgements................................................19 12.0 References......................................................19 Authors' Addresses...................................................19 Full Copyright Statement.............................................20 Acknowledgement......................................................20 Khartabil [Page 2] Internet Draft Congestion Safety and C-I October 2002 1.0 Terminology In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED" "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [5]. 2.0 Introduction The content-indirection service has gaind a lot of support from the SIP community lately. There have been many scenarios where content- indirection service can be useful. This document discusses this service and describes how it can be deployed in a network. This document covers, in more detail, the scenarios where senders, intermediaries and receivers of SIP messages may want to make use of the content-indirection service. A SIP UA originating a SIP request may not want to send SIP requests into the network, but instead chooses to publish a link to a URI where it has posted such content, using the mechanism described in [3]. This restriction is maybe due to charging, network configuration, or merely SIP message size constraints (the UA limiting its SIP transport to message oriented protocol such as UDP). Good examples of such SIP messages are MESSAGE [2] and PUBLISH [6]. The Session Initiation Protocol [1] allows the use of UDP for transport of SIP messages. The use of UDP with large payloads risks network congestion problems, as UDP itself does not define congestion prevention, detection, or correction mechanisms. Large SIP messages may cause UDP datagram fragmentation, something not desired by a network of SIP entities. The root of the problem lies with the SIP proxies. SIP proxies are able to convert the transport protocol from reliable to unreliable on hop-by-hop basis, therefore end-to-end congestion-safe path for SIP messages cannot be guaranteed. Conventional SIP payloads carry signalling information about media, but not media itself. There is potential that when a SIP infrastructure is shared between call signalling and instant messaging [2], the IM traffic will interfere with call signalling traffic. This also applies to other types of SIP Requests that have potential to carry large contents (NOTIFY is an example). Furthermore, mobile terminals might want to limit the size of a SIP message received regardless of the underlying transport protocol (e.g. TCP). This may be due to memory limitations or the fact that the radio link that the terminal is accessing at this instant is very slow and the user wants to postpone collecting data until a better link is acquired. Khartabil [Page 3] Internet Draft Congestion Safety and C-I October 2002 3.0 Overview of Operation The basic scenario is when a SIP request is being sent from a UA1 to a UA2 that has a home proxy. That SIP request could carry large contents. * * UA2 Domain * UA1 Domain * * * * +-------+ * +-------+ | UA2 | * | UA1 | / CSS | * | CSS \ //| | * | |\\ / +---+---+ * +---+---+ \ // | * | \ / | * | \\ / | * | \ +-------+ // +---+---+ * +---+---+ \ +-------+ | |/ | UA2 | * | UA1 | \\| | | UA2 +----------+ Home +---*---+ Home +----------* UA1 | | | | Proxy | * | Proxy | | | +-------+ +-------+ * +-------+ +-------+ * * * * * * * UA2 earlier has registered at the registrar co-located with the home proxy. UA2 may have indicated its maximum acceptable message size using the extensions defined in this document. UA1 has a choice to either send requests with large contents directly to its home proxy, or it can post the contents to its Content Storage Server (CSS) and then send the link to the posted content in the SIP request. Note that posting to the CSS does not need the precondition of large contents of a SIP message. In the first scenario, UA1 home proxy or UA2 home proxy receive the request with the large contents. They have the option of rejecting the request with a ô513 Message Too Largeö error response (congestion safety). UA2 home Proxy also has the option of forwarding the request to a Content Storage Server (CSS). That home Khartabil [Page 4] Internet Draft Congestion Safety and C-I October 2002 proxy learns the maximum acceptable message size from registration by UA2 (regardless of transport protocol) or through configuration. UA2 home proxy, unaware of the limitations, can forward the large message to UA2, who consequently, can reject the message with error response ô413 Request Entity Too Largeö. UA2 can indicate its maximum acceptable message size using extension in this document. UA2 home proxy receiving the ô413ö response can either just forward that response upstream or act as a B2BUA and resend the requested with content-indirection to the CSS. In the second scenario, UA1, using means outside the scope of this document, posts the contents of the SIP request to the CSS and sends the SIP request with a link to the contents as described in [3]. Home proxies can then fetch the contents and amend the SIP request, or it can be left up to UA2 to fetch the contents. The behaviour of the home proxies receiving the SIP request is described in more detail in the following chapters. 4.0 UA Behaviour 4.1 UAC Sending Requests A UAC has a choice to either send requests with large contents directly to a proxy, or it can post the contents to a Content Storage Server (CSS) and then send the link to the posted content in the SIP request. Note that posting to the CSS does not need the precondition of large contents in a SIP message. A UAC sending a SIP Request and wants to make sure that all proxies on the path are congestion-safe proxies MUST insert a ôProxy- Requireö header with the tag ôcongestion-safeö as described in [3]. 4.2 UAC Behaviour when receiving Response A SIP Response with large contents that exceed the limitations is discarded. If the transport protocol is connection-oriented, the connection MAY be closed to stop further sending of the response. 4.2.1 ô413ö or ô513ö Error Responses The max-size header MAY prompt the UAC of the request to send a newly formulated request immediately with either smaller contents or with content-indirection. If the Retry-After header is also present, the UAC MUST either wait for that time before sending the same request, or it immediately sends the newly formulated request. It SHOULD NOT resend exactly the same request within the retry-after period. The Retry-After value Khartabil [Page 5] Internet Draft Congestion Safety and C-I October 2002 MAY be used as an indication of how long this Max-Size constraint is valid for. Max-size header indicates the SIP message size the UAS can handle for the transport protocol used to send the request. This constraint SHOULD NOT be applied to the same Request sent on different transport protocol. If an Accept-header is present without the value message/external- body, the UAC MUST NOT send the new message with content-type: message/external-body. The UAC MAY use this Max-size value to send new, unrelated Requests to the same URI within the duration indicated by the retry-after header. For example: UserA sends a SIP MESSAGE with large content to userB. UserB rejects the request with ô413 Request Entity Too Largeö with a max-size header of value 1300 bytes and a Retry-After value of 80 seconds. UserA now needs to send an unrelated NOTIFY to userB, due to an earlier SUBSCRIBE. This NOTIFY will be sent within the 80 seconds specified. UserA MAY use the 1300 byte constraint to send the NOTIFY. This has to be done with care since the UAS receiving the NOTIFY could be different that the one that received the MESSAGE. The UAC has to be certain that UAS receiving the requests are the same. 4.3 UA Registering Desired Maximum SIP Message Size Having learnt its capabilities and limitations (by user input or other means), a SIP UA issuing a REGISTER request MAY indicate its acceptable maximum size for a SIP message (including headers and body). This section introduces a new SIP-URI parameter ômax-sizeö. A SIP UA registering its address will include this SIP-URI parameter in the contact-header supplied with the REGISTER request. If the transport parameter is present in the SIP URI of the contact header, then this max-size applies to that particular transport protocol. If transport parameter is not present, then this max-size applies to the default transport protocol used (UDP). Example REGISTER Request: REGISTER sip:registrar.nokia.com SIP/2.0 Via: SIP/2.0/UDP host1.nokia.com;branch=z9hG4bK346434r From: sip:hisham.khartabil@nokia.com;tag=31jrlkejrq3kl3jkl879defje3 To: sip:hisham.khartabil@nokia.com Contact: Call-Id: vjn86732nv4fgiofd CSeq: 1 REGISTER Max-Forwards:70 Khartabil [Page 6] Internet Draft Congestion Safety and C-I October 2002 Example REGISTER Request where the max-size applies to TCP: REGISTER sip:registrar.nokia.com SIP/2.0 Via: SIP/2.0/UDP host1.Nokia.com;branch=z9hG4bK346434r From: sip:hisham.khartabil@nokia.com;tag=31jrlkejrq3kl3jkl879defje3 To: sip:hisham.khartabil@nokia.com Contact: Call-Id: vjn86732nv4fgiofd CSeq: 1 REGISTER Max-Forwards:70 4.4 UAS Receiving A SIP Message With Large Contents A SIP UAS (terminal or application server like Presence Server) may not have indicated its willingness or capabilities in receiving large message content with the REGISTER request. This may be due to lack of knowledge by the UA, at the time of registration, of its memory or radio link constraints. A SIP UAS receiving a SIP Request it is unable to handle due to size, regardless of the underlying transport protocol, MAY reject the request with ô413 Request Entity Too Largeö. The UAS MAY close the connection, if the transport protocol was a reliable connection oriented one, to prevent the sender from continuing the request. If the condition is temporary, the UAS SHOULD include a Retry-After header field to indicate that this condition is temporary and after what time the sender can try to send the same request again. The UAS MAY also indicate its acceptable message size capabilities. Here we introduce a new SIP header ôMax-Sizeö. The ô413ö response sent back by the UAS MAY contain this header. This header contains the maximum acceptable message size by this UAS. The ô413ö response MAY also include an Accept-header with value message/external-body indicating its capability to handle content- indirection. Example response: SIP/2.0 413 Request Entity Too Large Via: SIP/2.0/UDP proxy.nokia.com;branch=z9hG4bK4kl5jr0iui0giu09df43 Via: SIP/2.0/UDP host1.somewhere.com;branch=z9hG4bK346434r From: sip:markus.isomaki@nokia.com;tag=4jk123vxbc96 To: sip:hisham.khartabil@nokia.com;tag=fsad98754b6b64m Call-Id: j4lk2j35879cvx7b CSeq: 1 MESSAGE Max-Size: 1300 Retry-After: 180 Max-Forwards:70 Accept: message/external-body Khartabil [Page 7] Internet Draft Congestion Safety and C-I October 2002 4.5 UAS Receiving a Request with Indirected Content A UAS may receive a SIP request that had content-indirection performed on it. In this case, the UAS MAY retrieve the contents from the CSS using the URI supplied (See [3] for more details), before it generates a response. It MAY retrieve the contents after it generates the response. If a request is an INVITE, the UAS MUST retrieve the contents before generating the response. 5.0 Proxy Behaviour 5.1 Congestion Safe Proxy A congestion safe proxy MUST be complaint with this specification as well as [3] and [4]. This proxy MUST understand the option tag ôcongestion-safeö. A congestion-safe proxy MUST be able to handle content-indirection if it is configured with a Content Storage Server (CSS) as described in section 4.2. If not configured with CSS, the proxy behave as described in [4] 5.2 Proxy Receiving A SIP Message With Large Content A proxy MAY be configured with a maximum allowable SIP message size that is destined to a recipient on a certain interface. This value is typically network configured with the lowest Maximum Transfer Unit (MTU) en route to the recipient (UAS) on that interface. The proxy server MUST only use the value when the recipient (UAS) is using UDP as the transport protocol. How this configuration is performed is out side the scope of this document. It is RECOMMENDED that dynamic discovery and configuration is performed. A proxy configured with this value is considered to be congestion-safe. The proxy MAY also learn the maximum size of a particular UA by means of registration as described in section 3.1 (Note in this case, the value may possibly not be the MTU). This scenario is possible when the registrar for a particular UA is co-located with the proxy (this entity is typically referred to as the home proxy). When both values are available to the home proxy (the one that arrives in the contact-header of a registration request and the locally configured value), and the transport protocol to be used is connectionless oriented (UDP), the smaller of the two values is used. If the registered URI uses connection-oriented protocol (such as TCP), then the configured value MUST be ignored. Khartabil [Page 8] Internet Draft Congestion Safety and C-I October 2002 When the proxy receives a request, it examines the message as follows: Note: This assumes that the proxy server has accepted to handle a request with size larger than the configured MTU or larger than the registered max-size for that recipient. If the proxy is not willing to do so, it simply rejects the request with ô513 Message Too Largeö. See section 4.3 for more details. 1. The proxy examines the SIP URI searching for host and transport to send the request to according to procedures in [1]. 2. The proxy also searches for the max-size parameter (if a home proxy) and for the configured maximum allowable message size for the interface it will send the request on. 3. If the proxy is a home proxy and transport protocol is TCP, there are 2 cases (since configured value is not used for TCP): a. The proxy is configured with a max message size value and the registered URI does not contain max-size parameter. In this case, the message size is compared to the configured value. If the message size is smaller, then processing proceeds as normal. If the message size is greater, content-indirection MAY be applied. See section 5.4 for more details. b. The proxy is not configured with this value and the registered URI does contain the max-size parameter. In this case, the message size is compared to the registered URI max-size parameter value. If the message size is smaller, then processing proceeds as normal. If the message size is greater, content-indirection MAY be applied. See section 5.4 for more details. 4. If the proxy is a home proxy and the transport protocol is UDP, there are 4 cases: a. Proxy is not configured with this value and registered URI does not contain max-size parameter. In this case, processing proceeds as described in [3]. b. Proxy is configured with this value and registered URI does not contain max-size parameter. In this case, the message size is compared to the configured value. If the message size is smaller, then processing proceeds as normal. If the message size is greater, content-indirection MAY be applied. See section 5.4 for more details. c. Proxy is not configured with this value and registered URI does contain max-size parameter. In this case, the message size is compared to the registered URI max-size parameter value. If the message size is smaller, then processing proceeds as normal. If the message size is greater, content-indirection MAY be applied. See section 5.4 for more details. Khartabil [Page 9] Internet Draft Congestion Safety and C-I October 2002 d. Proxy is configured with this value and registered URI does contain max-size parameter. In this case, the message size is compared to the smaller value of the two. If the message size is smaller, then processing proceeds as normal. If the message size is greater, content-indirection MAY be applied. See section 5.4 for more details. 5. If the proxy is not responsible for that domain receives the request and the transport protocol is a connection-oriented one, the request is simply forwarded 6. If the proxy is not responsible for that domain receives the request and the transport protocol is a connectionless one, there are 2 cases: a. Proxy is not configured with this value. In this case, processing proceeds as described in [4]. b. Proxy is configured with this value. In this case, the message size is compared to the configured value. If the message size is smaller, then processing proceeds as normal. If the message size is greater, content-indirection MAY be applied. See section 5.4 for more details. A SIP Response with large contents that exceeds the maximum acceptable size is discarded. If the transport protocol is connection-oriented, the connection MAY be closed to stop further sending of the response. 5.3 Proxy Refusing To Handle Large SIP Requests There are circumstances where the proxy refuses to perform content- indirection on a received SIP Request destined to a recipient where a maximum message size constraint has been imposed. These circumstances may include the user not paying for this service or simply that the proxy does not know how to perform content- indirection (see section 4.1 about a congestion safe proxy). The definitions of these circumstances are outside the scope of this document. In any case, when the proxy refuses to handle this situation or it is simply not a congestion safe proxy (does not understand the option tag ôcongestion-safeö), it returns a ô513 Message Too Largeö response. Reference [4] shows how a proxy SHOULD handle this situation. The ô513ö response MAY include an Accept-header with message/external-body. 5.4 Proxy Performing Content Indirection Khartabil [Page 10] Internet Draft Congestion Safety and C-I October 2002 A proxy that is a congestion safe proxy MUST handle content indirection. Here we define a new functional SIP entity called ôContent Storage Server (CSS). A congestion safe proxy MUST be configured with the CSS address. Once the home proxy has accepted to perform content indirection on a SIP Request, it forwards the message to the CSS. Section 16.6 of [1] defines the steps to follow. Pay special attention to step 6 where it discusses how a proxy may divert a SIP Request to a specific next hop. Below is a rewrite of that section tailored to the terminology used in this document: A proxy MAY mandate that a request visit a CSS before being delivered to the destination. This is to accommodate content indirection. A proxy MUST ensure that CSS is a loose router. Generally, this can only be known with certainty if the CSS is within the same administrative domain. The CSS is represented by a URI (which contains the lr parameter). This URI MUST be pushed into the Route header field ahead of any existing values, if present. If the Route header field is absent, it MUST be added, containing that URI. 5.5 Proxy Receiving ô413ö Response From Downstream Open issue: should we just choose to forward the response upstream? A UA or proxy refusing to handle a large SIP Request may reject the request with ô413ö error response as describe in section 3.2. When a proxy receives this response, it MAY choose to handle the request itself. It does so by reissuing the request, but this time, it sends it via the CSS using the route-header, as described in section 5.4. The proxy MAY also send a ô181 Call Is Being Forwardedö provisional response back to the sender. There are situations where the proxy refuses the handle the request itself and alternatively just forward the ô413ö response to sender. See section 5.3 for more details. 5.6 Proxy Receiving a Request With Indirected Content A proxy may receive a SIP request that had content-indirection performed on it. In this case, the proxy MAY perform one of 2 things: a. Retrieve the contents and amend the request to contain those contents. It is RECOMMENDED for a proxy to do so if the CSS in within the same administrative domain as the proxy. It is also RECOMMENDED for a proxy to do so if the CSS is not within the Khartabil [Page 11] Internet Draft Congestion Safety and C-I October 2002 administrative domain as the proxy, but there is a trust relationship between the two domains. The proxy sends the new request to the destination, maintaining any tags in the To and From headers sent in the original request. This is to accommodate for SIP requests within dialogs being delivered to the right dialog. b. Forward the request without retrieving the contents. It is NOT RECOMMENDED for a to proxy forwards the request without first retrieving the content and amending the request to contain it, if the CSS is within the same administrative domain as the proxy. 6.0 Content Storage Server (CSS) Behaviour The CSS behaves as a SIP Back To Back User Agent (B2BUA). When it receives a SIP Request performs the following steps: a. Extracts the body of the Request and stores it in an HTTP server. b. Responds to the sender with a ô202 Acceptedö response. INVITE is a special case. The CSS MUST NOT respond with ô202ö in this case, but instead wait for a response from the UAS. c. Formulates a new request that includes the URL where the content can be retrieved. This procedure is described in [3]. d. Sends the new request to the destination, maintaining any tags in the To and From headers sent in the original request. This is to accommodate for SIP requests within dialogs being delivered to the right dialog. OPEN ISSUE: Should the behaviour of CSS be uniform across all requests? I.e. Not generate a ô202ö response at all. 7.0 Syntax for Extensions 7.1 Max-Size Header Max-Size = ôMax-Sizeö HCOLON delta-seconds Additions to SIP Table 3: Header field where proxy ACK BYE CAN INV OPT REG ----------------------------------------------------------- Max-Size 413 a - - - - - - 7.2 Max-size parameter Max-size-param = ômax-size=ö 1*DIGIT Khartabil [Page 12] Internet Draft Congestion Safety and C-I October 2002 8.0 Security considerations The presence of Max-size header in a SIP message has a significant effect on the ways in which the request is handled at a server. As a result, it is especially important that messages containing this extension be authenticated. The same holds true for registrations with contact parameters. Processing of requests and looking up criteria for message size requires set operations and searches, which can require some amount of computation. This enables a DoS attack whereby a user can send requests with substantial numbers messages with large contents, in the hopes of overloading the server. To counter this, the server SHOULD authenticate the sender. REGISTER requests can reveal sensitive information about a UAÆs capabilities. If this information is sensitive, it SHOULD be encrypted using SIP S/MIME capabilities. 9.0 Examples 9.1 UAC Posting Contents to CSS Before Sending SIP MESSAGE UA2 UA2 UA1 UA1 UA1 Home Home CSS Proxy Proxy | | | | | | | | | | | | | | (F1) post | | | | |<------------->| | | | | | | | | | | | | | | (F2) MESSAGE | | | |<------------------------------| | | | | | | | | | | | | | (F3) get | | | | |<------------->| | | | (F4) MESSAGE | | | | |<--------------| | | | (F5) MESSAGE | | | | |<--------------| | | | | | | | | | | | | | |(F6) 200 Ok | | | | |-------------->| (F7) 2OO Ok | | | | |-------------->| (F8) 200 Ok | | | | |------------------------------>| | | | | | | | | | | Khartabil [Page 13] Internet Draft Congestion Safety and C-I October 2002 | | | | | | | | | | | | | | | | | | | | (F1) UA1 posts, using some means outside this document, the contents to the CSS (F2) UA1 sends the SIP MESSAGE with content-type: message/external- body MESSAGE sip:ua2@nokia.com SIP/2.0 Via: SIP/2.0/UDP host1.somewhere.com;branch=z9hG4bK346434r From: sip:ua1@somewhere.com;tag=31jrlkejrq3kl3jkl879defje3 To: sip:ua1@nokia.com Contact: Call-Id: vjn86732nv4fgiofd CSeq: 1 MESSAGE Max-Forwards: 70 Content-Type: message/external-body; access-type=URL; url="http://131.228.13.2/im/9207807c03d4a5e0e6907b0dc89c9067"; Content-Length: 32 Content-Type: text/html (F3) UA1 home proxy fetches the contents and amends the SIP MESSAGE with the new contents (F4) Newly constructed MESSAGE send to the domain of the recipient MESSAGE sip:ua2@nokia.com SIP/2.0 Via: SIP/2.0/TCP au1-homeproxy.nokia.com;branch=z9hG4bKewrlkjdfkjl Via: SIP/2.0/UDP host1.somewhere.com;branch=z9hG4bK346434r From: sip:ua1@somewhere.com;tag=31jrlkejrq3kl3jkl879defje3 To: sip:ua1@nokia.com Call-Id: vjn86732nv4fgiofd CSeq: 1 MESSAGE Max-Forwards: 69 Content-type: text/html Content-length: 20000 [Large Body] (F5) UA2 home proxy decides that the content of this message is not too large and therefore does not perform content redirection of the message (F6) û (F8) ô200 Okö for the request. Khartabil [Page 14] Internet Draft Congestion Safety and C-I October 2002 9.2 Receiving A MESSAGE With Large Contents after a REGISTER, Home Proxy Performs Content-Indirection UA2 CSS UA2 UA1 Home Proxy | | | | | | | | | (F1) REGISTER | | | |-------------------------------------->| | | | | | | | (F2) 200 Ok | | |<--------------------------------------| | | | | | | | | | | | | | | | | (F3) MESSAGE | | | |<------------------| | | (F4) MESSAGE | | | |<------------------| | | | | | | | | | | | (F5) 202 Accepted | | | |------------------>| | | (F7) MESSAGE | | (F6) 202 Accepted | |<------------------| |------------------>| | | | | | | | | | (F8) 200 Ok | | | |------------------>| | | | | | | | | | | | | | | (F1) REGISTER sent from UA2 to Home Proxy (Registrar) REGISTER sip:registrar.nokia.com SIP/2.0 Via: SIP/2.0/UDP host2.somewhere.com;branch=z9hG4bKue73jhhdue From: sip:ua2@somewhere.com;tag=48er8fdjkcfnciue9843ifj To: sip:ua2@somewhere.com Call-Id: 3mkejdc9e9834judjd CSeq: 1 REGISTER Expires: 3600 Contact: Max-Forwards: 70 (F2) 200 Ok from Home proxy to UA2 SIP/2.0 200 Ok Via: SIP/2.0/UDP host2.somewhere.com;branch=z9hG4bKue73jhhdue From: sip:ua2@somewhere.com;tag=48er8fdjkcfnciue9843ifj To: sip:ua2@somewhere.com;tag=393k3lmn3n3934 Khartabil [Page 15] Internet Draft Congestion Safety and C-I October 2002 Call-Id: 3mkejdc9e9834judjd CSeq: 1 REGISTER Contact: ,expires=3600 Max-Forwards: 70 (F3) Message sent from UA1 to UA2 with very large content MESSAGE sip:ua2@nokia.com SIP/2.0 Via: SIP/2.0/UDP host1.somewhere.com;branch=z9hG4bK346434r From: sip:ua1@somewhere.com;tag=31jrlkejrq3kl3jkl879defje3 To: sip:ua1@nokia.com Call-Id: vjn86732nv4fgiofd CSeq: 1 MESSAGE Max-Forwards: 70 Content-type: text/html Content-length: 20000 [Large Body] (F4) MESSAGE is directed by UA2's home proxy to CSS. Home proxy accepts to content-indirect MESSAGE sip:ua2@nokia.com SIP/2.0 Via: SIP/2.0/TCP homeproxy.nokia.com;branch=z9hG4bKewrlkjdfkjl Via: SIP/2.0/UDP host1.somewhere.com;branch=z9hG4bK346434r From: sip:ua1@somewhere.com;tag=31jrlkejrq3kl3jkl879defje3 To: sip:ua1@nokia.com Call-Id: vjn86732nv4fgiofd CSeq: 1 MESSAGE Route: sip:css.nokia.com Max-Forwards: 69 Content-type: text/html Content-length: 20000 [Large Body] (F5) CCS returns a 202 Accepted SIP/2.0 202 Accepted Via: SIP/2.0/TCP homeproxy.nokia.com;branch=z9hG4bKewrlkjdfkjl Via: SIP/2.0/UDP host1.somewhere.com;branch=z9hG4bK346434r From: sip:ua1@somewhere.com;tag=31jrlkejrq3kl3jkl879defje3 To: sip:ua1@nokia.com;tag=5nixucvzo3241bqewmn Contact: Call-Id: vjn86732nv4fgiofd CSeq: 1 MESSAGE Max-Forwards: 70 (F6) Home proxy forwards response to UA1 SIP/2.0 202 Accepted Via: SIP/2.0/UDP host1.somewhere.com;branch=z9hG4bK346434r From: sip:ua1@somewhere.com;tag=31jrlkejrq3kl3jkl879defje3 Khartabil [Page 16] Internet Draft Congestion Safety and C-I October 2002 To: sip:ua1@nokia.com;tag=5nixucvzo3241bqewmn Contact: Call-Id: vjn86732nv4fgiofd CSeq: 1 MESSAGE Max-Forwards: 69 (F7) CCS sends the content-indirected MESSAGE to UA2 with the URL MESSAGE sip:ua2@nokia.com SIP/2.0 Via: SIP/2.0/UDP css.nokia.com;branch=z9hG4bK342kj5klj43klndsm From: sip:ua1@somewhere.com;tag=31jrlkejrq3kl3jkl879defje3 To: sip:ua1@nokia.com Contact: Call-Id: vjn86732nv4fgiofd CSeq: 1 MESSAGE Max-Forwards: 70 Content-Type: message/external-body; access-type=URL; url="http://131.228.13.2/im/9207807c03d4a5e0e6907b0dc89c9067"; Content-Length: 32 Content-Type: text/html (F8) 200 Ok is returned by UA2 SIP/2.0 200 Ok Via: SIP/2.0/UDP css.nokia.com;branch=z9hG4bK342kj5klj43klndsm From: sip:ua1@somewhere.com;tag=31jrlkejrq3kl3jkl879defje3 To: sip:ua1@nokia.com;tag=dfjkla43kjl5ldskfj Contact: Call-Id: vjn86732nv4fgiofd CSeq: 1 MESSAGE Max-Forwards: 70 9.3 Receiving A NOTIFY With Large Contents, UAS Refuses To Handle Request This example assumes that a subscription has been established. It also assumes that UA2 has not registered a max-size limit and that the home proxy configured max-size is less than the size of the NOTIFY. UA2 CSS UA2 PS Home Proxy | | | | | | | (F1) NOTIFY | | | |<------------------| | | | | | (F2) NOTIFY | | | |<--------------------------------------| | | | | | Khartabil [Page 17] Internet Draft Congestion Safety and C-I October 2002 | | (F3) 413 | | |-------------------------------------->| | | | | (F4) 413 | | | |------------------>| | | | | (F1) NOTIFY sent from PS to UA2, via home proxy with very large content NOTIFY sip:ua2@host2.nokia.com SIP/2.0 Via: SIP/2.0/TCP ps.nokia.com;branch=z9hG4bK346434r From: sip:ps.nokia.com;tag=31jrlkejrq3kl3jkl879defje3 To: sip:ua2@nokia.com;tag=eqwriuo423nf Call-Id: vjn86732nv4fgiofd CSeq: 2 NOTIFY Route: sip: homeproxy.nokia.com Max-Forwards: 70 Content-Type: application/cpim-pidf+xml Content-length: 20000 [Large Body] (F2) NOTIFY forwarded from home proxy to UA2 with very large content. Home proxy checked its max-size configuration and found that this message passes. NOTIFY sip:ua2@host2.nokia.com SIP/2.0 Via: SIP/2.0/TCP homeproxy.nokia.com;branch=z9hG4bKre78re89jfdkj Via: SIP/2.0/TCP ps.nokia.com;branch=z9hG4bK346434r From: sip:ps.nokia.com;tag=31jrlkejrq3kl3jkl879defje3 To: sip:ua2@nokia.com;tag=eqwriuo423nf Call-Id: vjn86732nv4fgiofd CSeq: 2 NOTIFY Max-Forwards: 69 Content-Type: application/cpim-pidf+xml Content-length: 20000 [Large Body] (F3) UA2 refuses the request due to its large content and returns a 413 response SIP/2.0 413 Message Too Large Via: SIP/2.0/TCP homeproxy.nokia.com;branch=z9hG4bKre78re89jfdkj Via: SIP/2.0/TCP ps.nokia.com;branch=z9hG4bK346434r From: sip:ps.nokia.com;tag=31jrlkejrq3kl3jkl879defje3 To: sip:ua2@nokia.com;tag=eqwriuo423nf Call-Id: vjn86732nv4fgiofd CSeq: 2 NOTIFY Max-size: 1300 Max-Forwards: 70 Khartabil [Page 18] Internet Draft Congestion Safety and C-I October 2002 (F4) 413 passed by home proxy to PS. Home proxy did not content- indirect. SIP/2.0 413 Message Too Large Via: SIP/2.0/TCP ps.nokia.com;branch=z9hG4bK346434r From: sip:ps.nokia.com;tag=31jrlkejrq3kl3jkl879defje3 To: sip:ua2@nokia.com;tag=eqwriuo423nf Call-Id: vjn86732nv4fgiofd CSeq: 2 NOTIFY Max-size: 1300 Max-Forwards: 69 10.0 IANA Considerations Once the header and parameter names have been agreed on, they will be registered with IANA. 11.0 Acknowledgements I would like to thank Jose Costa-Requena, Mikko Lonnfors, Pekka Pessi and Nokia for their comments and support. 12.0 References [1] J. Rosenberg, et al. ôSIP: Session Initiation Protocolö. RCF 3261, Internet Engineering Task Force, June 2002. [2] B. Campbell et al. "SIP Extensions for Instant Messaging", RFC3428, Internet Engineering Task Force, December 2002. [3] S. Olson. "A Mechanism for Content Indirection is SIP Messages", draft-ietf-sip-content-indirect-mech-01.txt. Internet Draft, Internet Engineering Task Force, November 2002. Work in progress. [4] D. Willis. "SIP Extension to Assure Congestion Safety", draft- ietf-sip-congestsafe-00.txt. Internet Draft, Internet Engineering Task Force, August 2002. Work in progress. [5] S. Bradner, "Key words for use in RFCs to indicate requirement levels," RFC 2119, Internet Engineering Task Force, Mar. 1997. [3] S. Olson. Et al. "SIMPLE Presence Publication Mechanism", draft- olson-simple-publish-01. Internet Draft, Internet Engineering Task Force, October 2002. Work in progress. Authors' Addresses Hisham Khartabil Nokia P.O. Box 321 Khartabil [Page 19] Internet Draft Congestion Safety and C-I October 2002 FIN-00045 NOKIA GROUP FINLAND Email: Hisham.Khartabil@nokia.com Tel: + 358 7180 76161 Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Khartabil [Page 20] --------------4CF01AB8B5C22B7DB1C66030-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Tue Mar 11 11:36:49 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26490 for ; Tue, 11 Mar 2003 11:36:48 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2BGoKl11830 for sip-archive@odin.ietf.org; Tue, 11 Mar 2003 11:50:20 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BGkYO11644; Tue, 11 Mar 2003 11:46:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BGfsO11434 for ; Tue, 11 Mar 2003 11:41:54 -0500 Received: from mail.aastra.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26122 for ; Tue, 11 Mar 2003 11:27:51 -0500 (EST) Received: by mail.aastra.com with Internet Mail Service (5.5.2653.19) id <1XVB0BZH>; Tue, 11 Mar 2003 11:19:25 -0500 Message-ID: From: Sumit Garg To: sip@ietf.org Date: Tue, 11 Mar 2003 11:19:15 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C2E7E9.F5DFDB40" Subject: [Sip] RFC 3398: REL cause Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This 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_000_01C2E7E9.F5DFDB40 Content-Type: text/plain; charset="iso-8859-1" According to the rfc 3398(SIP-ISUP mapping, section 7.1.3 and 7.2.2),for a net to Phone call, when ACM timeout timer (T7- 20 - 30 s) expires, the ISUP leg REL cause should be 102 (protocol error, recovery on timer expiry) and corresponding SIP response should be 504 Server Timeout. However, if one goes by Q.764 and table 1 of Q.850 the correct REL cause for ISUP would be 31(normal unspecified) and for the SIP leg it would then correspond to 480 (Temporarily Unavailable). Apparently 102 is used mostly for SUS-RES. What should be the values used? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Sumit Garg Aastra Telecom US 8 Federal Street Billerica, MA 01821 978-436-4244 email: <> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ------_=_NextPart_000_01C2E7E9.F5DFDB40 Content-Type: application/octet-stream; name="Sumit Garg.vcf" Content-Disposition: attachment; filename="Sumit Garg.vcf" BEGIN:VCARD VERSION:2.1 N:Garg;Sumit FN:Sumit Garg ORG:Aastra Network Access NOTE:Aastra CVX TEL;WORK;VOICE:978-436-4244 ADR;WORK:;Boston;8 Federal Street;Billerica;MA;1821;USA LABEL;WORK;ENCODING=QUOTED-PRINTABLE:Boston=0D=0A8 Federal Street=0D=0ABillerica, MA 1821=0D=0AUSA EMAIL;PREF;INTERNET:sgarg@aastra.com REV:20021122T160021Z END:VCARD ------_=_NextPart_000_01C2E7E9.F5DFDB40-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Tue Mar 11 20:19:58 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21919 for ; Tue, 11 Mar 2003 20:19:58 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2C1XfY19584 for sip-archive@odin.ietf.org; Tue, 11 Mar 2003 20:33:41 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2C1X2O19546; Tue, 11 Mar 2003 20:33:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2C1T8O19343 for ; Tue, 11 Mar 2003 20:29:08 -0500 Received: from bdsl.greycouncil.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21738 for ; Tue, 11 Mar 2003 20:14:53 -0500 (EST) Received: from txdwillis (bdsl.66.12.12.254.gte.net [66.12.12.254]) (authenticated bits=0) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h2C1GW49016609 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 11 Mar 2003 19:16:33 -0600 From: "Dean Willis" To: Cc: "Gonzalo Camarillo" , "Jon Peterson \(jon.peterson@NeuStar.com\)" , "Rohan Mahy" Date: Tue, 11 Mar 2003 19:16:25 -0600 Message-ID: <008c01c2e835$00efee30$ee036e3f@txdwillis> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2C1T8O19344 Subject: [Sip] Draft agenda, SIP Working Group Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Ok, here's the current working draft agenda for SIP WG. Please feedback asap if you have issues/suggestions. Posted at: http://www.softarmor.com/sipwg/meets/ietf56/agenda.html Monday, March 17, 1300-1500, Continental 6 1300 Agenda Bash 1305 Status -- Chairs 1315 Non-Invite Transaction Issues, Robert Sparks draft-sparks-sip-noninvite-00.txt 1330 Referred-By Changes and Open Issues, Robert Sparks draft-ietf-sip-referredby-01.txt 1340 Resource Priority, Henning Schulzrinne draft-polk-sip-resource-02.txt 1355 Caller Preferences, Jonathan Rosenberg draft-ietf-sip-callerprefs-08.txt 1410 Congestion Safety, Dean Willis, Hisham Khartabil draft-ietf-sip-congestsafe-01.txt draft-khartabil-sip-congestionsafe-ci-02.txt 1430 General Discussion 1500 Break _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Tue Mar 11 20:57:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22780 for ; Tue, 11 Mar 2003 20:57:32 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2C2BGq22476 for sip-archive@odin.ietf.org; Tue, 11 Mar 2003 21:11:16 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2C2ArO22440; Tue, 11 Mar 2003 21:10:53 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2C27xO22342 for ; Tue, 11 Mar 2003 21:07:59 -0500 Received: from iere.net.avaya.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22714 for ; Tue, 11 Mar 2003 20:53:44 -0500 (EST) Received: from iere.net.avaya.com (localhost [127.0.0.1]) by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id h2C1r3Z13106 for ; Tue, 11 Mar 2003 20:53:03 -0500 (EST) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id h2C1r2J13093 for ; Tue, 11 Mar 2003 20:53:02 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sip] Draft agenda, SIP Working Group Date: Wed, 12 Mar 2003 03:55:51 +0200 Message-ID: Thread-Topic: [Sip] Draft agenda, SIP Working Group Thread-Index: AcLoOaRaUwmuZAlpTQGJVIOLtc+RyAAALA2A From: "Romascanu, Dan (Dan)" To: "Dean Willis" , Cc: "Gonzalo Camarillo" , "Jon Peterson (jon.peterson@NeuStar.com)" , "Rohan Mahy" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2C27xO22343 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Is there any intention to include the SIP MIB on the agenda? Thanks, Dan > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Wednesday, March 12, 2003 3:16 AM > To: sip@ietf.org > Cc: Gonzalo Camarillo; Jon Peterson > (jon.peterson@NeuStar.com); Rohan Mahy > Subject: [Sip] Draft agenda, SIP Working Group > > > > Ok, here's the current working draft agenda for SIP WG. > Please feedback asap > if you have issues/suggestions. > > > Posted at: > > http://www.softarmor.com/sipwg/meets/ietf56/agenda.html > > > Monday, March 17, 1300-1500, Continental 6 > > > 1300 Agenda Bash > 1305 Status -- Chairs > 1315 Non-Invite Transaction Issues, Robert Sparks > draft-sparks-sip-noninvite-00.txt > 1330 Referred-By Changes and Open Issues, Robert Sparks > draft-ietf-sip-referredby-01.txt > 1340 Resource Priority, Henning Schulzrinne > draft-polk-sip-resource-02.txt > 1355 Caller Preferences, Jonathan Rosenberg > draft-ietf-sip-callerprefs-08.txt > 1410 Congestion Safety, Dean Willis, Hisham Khartabil > draft-ietf-sip-congestsafe-01.txt > draft-khartabil-sip-congestionsafe-ci-02.txt > 1430 General Discussion > 1500 Break > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Wed Mar 12 10:40:30 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08360 for ; Wed, 12 Mar 2003 10:40:30 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2CFsTD21397 for sip-archive@odin.ietf.org; Wed, 12 Mar 2003 10:54:29 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CFrjO21340; Wed, 12 Mar 2003 10:53:45 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CFnvO21165 for ; Wed, 12 Mar 2003 10:49:57 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08067 for ; Wed, 12 Mar 2003 10:35:26 -0500 (EST) From: hisham.khartabil@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2CFf3F18064 for ; Wed, 12 Mar 2003 17:41:03 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 12 Mar 2003 17:37:27 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 12 Mar 2003 17:37:23 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 12 Mar 2003 17:37:22 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Wed, 12 Mar 2003 17:37:22 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7FE739E@esebe019.ntc.nokia.com> Thread-Topic: NOTIFY establishes a dialog Thread-Index: AcLorUZXIKW9Ox8mR6CJcIp4fE/dfA== To: X-OriginalArrivalTime: 12 Mar 2003 15:37:22.0940 (UTC) FILETIME=[467D53C0:01C2E8AD] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2CFnvO21166 Subject: [Sip] NOTIFY establishes a dialog Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit In RFC3265, it is mentioned that NOTIFY can certainly establish a dialog if it arrives before the 200 of a SUBSCRIBE. What happens when the 200 for the SUBSCRIBE now arrives with record-route headers? Does the route-set get updated? (keeping in mind that the dialog is now in the established state). Regards, Hisham _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Wed Mar 12 12:13:17 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11754 for ; Wed, 12 Mar 2003 12:13:17 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2CHRId28916 for sip-archive@odin.ietf.org; Wed, 12 Mar 2003 12:27:18 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CHQZO28756; Wed, 12 Mar 2003 12:26:35 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CH5KO26605 for ; Wed, 12 Mar 2003 12:05:20 -0500 Received: from bdsl.greycouncil.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10746 for ; Wed, 12 Mar 2003 11:50:47 -0500 (EST) Received: from txdwillis (bdsl.66.12.12.254.gte.net [66.12.12.254]) (authenticated bits=0) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h2CGpW49022903 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Wed, 12 Mar 2003 10:51:32 -0600 From: "Dean Willis" To: "'Romascanu, Dan \(Dan\)'" , Cc: "'Gonzalo Camarillo'" , "'Jon Peterson \(jon.peterson@NeuStar.com\)'" , "'Rohan Mahy'" Subject: RE: [Sip] Draft agenda, SIP Working Group Date: Wed, 12 Mar 2003 10:51:22 -0600 Message-ID: <001a01c2e8b7$9d37e360$ee036e3f@txdwillis> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2CH5KO26606 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Well, I don't recall that any of the MIB authors indicated that there was any need for face time to discuss the MIB (of course, they might hve, and I might have been asleep). That, of course, may or may not be what the rest of the working group thinks. Do we need to discuss the MIB? Any controversial and unresolved issues that need to be talked through in the full group? It would be "nice" to move the MIB along, now that 3261 and the other major elements associated with it have basically stabilized. -- Dean > -----Original Message----- > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > Sent: Tuesday, March 11, 2003 7:56 PM > To: Dean Willis; sip@ietf.org > Cc: Gonzalo Camarillo; Jon Peterson > (jon.peterson@NeuStar.com); Rohan Mahy > Subject: RE: [Sip] Draft agenda, SIP Working Group > > > Is there any intention to include the SIP MIB on the agenda? > > Thanks, > > Dan > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Wed Mar 12 12:44:16 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13018 for ; Wed, 12 Mar 2003 12:44:16 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2CHwID31035 for sip-archive@odin.ietf.org; Wed, 12 Mar 2003 12:58:18 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CHvnO31001; Wed, 12 Mar 2003 12:57:49 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CHsbO30877 for ; Wed, 12 Mar 2003 12:54:37 -0500 Received: from znsgs01r.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12665 for ; Wed, 12 Mar 2003 12:40:03 -0500 (EST) Received: from znsgy0k8.europe.nortel.com (znsgy0k8.europe.nortel.com [47.165.24.67]) by znsgs01r.nortelnetworks.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2CHg9H14062; Wed, 12 Mar 2003 17:42:09 GMT Received: from zwcwc012.europe.nortel.com ([47.160.46.124]) by znsgy0k8.europe.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id GR682TY3; Wed, 12 Mar 2003 17:42:09 -0000 Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 12 Mar 2003 17:41:21 -0000 Message-ID: X-Sybari-Space: 00000000 00000000 00000000 From: "Mark Watson" To: sip@ietf.org, "'jon.peterson@neustar.biz'" Subject: RE: [Sip] I-D ACTION:draft-ietf-sip-identity-01.txt Date: Wed, 12 Mar 2003 17:41:12 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2E8BE.931D6E48" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This 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_01C2E8BE.931D6E48 Content-Type: text/plain; charset="iso-8859-1" Jon, Not sure if this was in the previous version, but I have a comment on the following from the introduction: "Coincidentally, the address-of-record URI of a SIP user is also the URI with which a SIP UA populates the From header of requests from that user - in other words, the address-of-record is an identity. So in this context users already have a means of providing their identity, which makes good sense: since the contents of a From header field are essentially a 'return address' for SIP requests, being able to prove that you are eligible to receive requests for that 'return address' should be identical to proving that you are authorized to assert this identity." I agree that prove of eligability to receive requests for an address is a sufficient condition for being authorised to assert an identity, but I do not think it is necessary. I can imagine scenarios in which I am authorised to assert an address as my identity, but I am not eligable to receive requests for that address. Just because I have an outgoing call service does not mean I have an incoming calls service. So, I suggest replacing "identical to proving" with "sufficient to prove" in the above paragraph. Regards...Mark > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: 07 March 2003 20:39 > Cc: sip@ietf.org > Subject: [Sip] I-D ACTION:draft-ietf-sip-identity-01.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 : Enhancements for Authenticated > Identity Management > in the Session Initiation Protocol (SIP) > Author(s) : J. Peterson > Filename : draft-ietf-sip-identity-01.txt > Pages : 16 > Date : 2003-3-7 > > The existing mechanisms for expressing identity in the Session > Initiation Protocol oftentimes do not permit an administrative domain > to verify securely the identity of the originator of a request. This > document recommends practices and conventions for authenticating end > users, and proposes a way to distribute cryptographically secure > authenticated identities within SIP messages. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-sip-identity-01.txt > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body > of the message. > > Internet-Drafts are also available by anonymous FTP. Login > with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-sip-identity-01.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-sip-identity-01.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant > mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > ------_=_NextPart_001_01C2E8BE.931D6E48 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Sip] I-D ACTION:draft-ietf-sip-identity-01.txt

Jon,

Not sure if this was in the previous version, but I = have a comment on the following from the introduction:

  "Coincidentally, the address-of-record = URI of a SIP user is also the
   URI with which a SIP UA populates the = From header of requests from
   that user - in other words, the = address-of-record is an identity.  So
   in this context users already have a = means of providing their
   identity, which makes good sense: since = the contents of a From header
   field are essentially a 'return = address' for SIP requests, being able
   to prove that you are eligible to = receive requests for that 'return
   address' should be identical to proving = that you are authorized to
   assert this identity."

I agree that prove of eligability to receive requests = for an address is a sufficient condition for being authorised to assert = an identity, but I do not think it is necessary.

I can imagine scenarios in which I am authorised to = assert an address as my identity, but I am not eligable to receive = requests for that address. Just because I have an outgoing call service = does not mean I have an incoming calls service.

So, I suggest replacing "identical to = proving" with "sufficient to prove" in the above = paragraph.

Regards...Mark

> -----Original Message-----
> From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org= ]
> Sent: 07 March 2003 20:39
> Cc: sip@ietf.org
> Subject: [Sip] I-D = ACTION:draft-ietf-sip-identity-01.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           : = Enhancements for Authenticated
> Identity Management
>       =         =           in the Session = Initiation Protocol (SIP)
>       = Author(s)       : J. Peterson
>       = Filename        : = draft-ietf-sip-identity-01.txt
>       = Pages           : = 16
>       = Date            : = 2003-3-7
>      
> The existing mechanisms for expressing identity = in the Session
> Initiation Protocol oftentimes do not permit an = administrative domain
> to verify securely the identity of the = originator of a request.  This
> document recommends practices and conventions = for authenticating end
> users, and proposes a way to distribute = cryptographically secure
> authenticated identities within SIP = messages.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-sip-ide= ntity-01.txt
>
> To remove yourself from the IETF Announcement = list, send a message to
> ietf-announce-request with the word unsubscribe = in the body
> of the message.
>
> Internet-Drafts are also available by anonymous = FTP. Login
> with the username
> "anonymous" and a password of your = e-mail address. After logging in,
> type "cd internet-drafts" and = then
>       "get = draft-ietf-sip-identity-01.txt".
>
> A list of Internet-Drafts directories can be = found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
> Internet-Drafts can also be obtained by = e-mail.
>
> Send a message to:
>       = mailserv@ietf.org.
> In the body type:
>       "FILE = /internet-drafts/draft-ietf-sip-identity-01.txt".
>      
> NOTE: The mail server at ietf.org can return = the document in
>       MIME-encoded = form by using the "mpack" utility.  To use this
>       feature, insert = the command "ENCODING mime" before the = "FILE"
>       command.  = To decode the response(s), you will need "munpack" or
>       a MIME-compliant = mail reader.  Different MIME-compliant
> mail readers
>       exhibit = different behavior, especially when dealing with
>       = "multipart" MIME messages (i.e. documents which have been = split
>       up into multiple = messages), so check your local documentation on
>       how to = manipulate these messages.
>       =        
>       =        
> Below is the data which will enable a MIME = compliant mail reader
> implementation to automatically retrieve the = ASCII version of the
> Internet-Draft.
>

------_=_NextPart_001_01C2E8BE.931D6E48-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Wed Mar 12 13:15:15 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14420 for ; Wed, 12 Mar 2003 13:15:15 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2CITIs01281 for sip-archive@odin.ietf.org; Wed, 12 Mar 2003 13:29:18 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CISlO01212; Wed, 12 Mar 2003 13:28:47 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CIOFO00989 for ; Wed, 12 Mar 2003 13:24:15 -0500 Received: from rtp-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14258 for ; Wed, 12 Mar 2003 13:09:41 -0500 (EST) Received: from dingdong.cisco.com (IDENT:mirapoint@dingdong.cisco.com [64.102.17.16]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2CIBkSc028148; Wed, 12 Mar 2003 13:11:47 -0500 (EST) Received: from cisco.com (klingle-ultra.cisco.com [64.102.93.47]) by dingdong.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ABS54469; Wed, 12 Mar 2003 13:08:06 -0500 (EST) Message-ID: <3E6F7862.2E9E641F@cisco.com> Date: Wed, 12 Mar 2003 13:11:46 -0500 From: Kevin Lingle X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Dean Willis CC: "'Romascanu, Dan (Dan)'" , sip@ietf.org, "'Gonzalo Camarillo'" , "'Jon Peterson (jon.peterson@NeuStar.com)'" , "'Rohan Mahy'" Subject: Re: [Sip] Draft agenda, SIP Working Group References: <001a01c2e8b7$9d37e360$ee036e3f@txdwillis> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Dean Willis wrote: > > Well, I don't recall that any of the MIB authors indicated that there was > any need for face time to discuss the MIB (of course, they might hve, and I > might have been asleep). That, of course, may or may not be what the rest of > the working group thinks. we (mib authors) did not ask for time on the agenda. > > Do we need to discuss the MIB? Any controversial and unresolved issues that > need to be talked through in the full group? > > It would be "nice" to move the MIB along, now that 3261 and the other major > elements associated with it have basically stabilized. agreed. we recently published -05 revision and expect to push out -06 because there were a few loose ends. after passing wg lc last year w/ rev -04, we determined it prudent to make the mib modules relevant to rfc3261. our ability to get around do doing that work was hampered by a number of factors. the result of that work is rev -05. we very much wish -06 to be the last revision so the mib can be moved along to iesg. besides the last call review we had last year on rev -04, we've not had what i would consider significant review of mib modules by the sip community over the life of the draft. mibs are not all that interesting to most folks it seems ;) it does give me some concern that what we are producing may or may not have the "right stuff". so, it would be great if more folks could take a look at http://ietf.org/internet-drafts/draft-ietf-sip-mib-05.txt and provide feedback. it's still not too late ;) kevin > > -- > Dean > > > -----Original Message----- > > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > > Sent: Tuesday, March 11, 2003 7:56 PM > > To: Dean Willis; sip@ietf.org > > Cc: Gonzalo Camarillo; Jon Peterson > > (jon.peterson@NeuStar.com); Rohan Mahy > > Subject: RE: [Sip] Draft agenda, SIP Working Group > > > > > > Is there any intention to include the SIP MIB on the agenda? > > > > Thanks, > > > > Dan > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Kevin R. Lingle 919.392.2029 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Wed Mar 12 13:26:12 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14749 for ; Wed, 12 Mar 2003 13:26:11 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2CIeF302709 for sip-archive@odin.ietf.org; Wed, 12 Mar 2003 13:40:15 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CIcJO02559; Wed, 12 Mar 2003 13:38:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CIZgO01714 for ; Wed, 12 Mar 2003 13:35:42 -0500 Received: from mail.cit.ie (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14640 for ; Wed, 12 Mar 2003 13:21:07 -0500 (EST) Received: from EEB174W2Kvk (unverified [157.190.81.172]) by cit.ie (Rockliffe SMTPRA 5.2.5) with SMTP id for ; Wed, 12 Mar 2003 18:22:26 +0000 Reply-To: From: "Valerie Kenneally" To: Date: Wed, 12 Mar 2003 18:23:19 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Content-Transfer-Encoding: 7bit Subject: [Sip] From/To "tag" parameter Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi All, Is it possible for a From tag and/or To tag parameter to contain a semi-colon? Valerie -------------------Legal Disclaimer--------------------------------------- The above electronic mail transmission is confidential and intended only for the person to whom it is addressed. Its contents may be protected by legal and/or professional privilege. Should it be received by you in error please contact the sender at the above quoted email address. Any unauthorised form of reproduction of this message is strictly prohibited. The Institute does not guarantee the security of any information electronically transmitted and is not liable if the information contained in this communication is not a proper and complete record of the message as transmitted by the sender nor for any delay in its receipt. ---------------------------------------------------------------------------------------- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Wed Mar 12 14:32:15 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17527 for ; Wed, 12 Mar 2003 14:32:15 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2CJkKH07572 for sip-archive@odin.ietf.org; Wed, 12 Mar 2003 14:46:20 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CJjpO07498; Wed, 12 Mar 2003 14:45:51 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CJfqO07245 for ; Wed, 12 Mar 2003 14:41:52 -0500 Received: from mail.cit.ie (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17182 for ; Wed, 12 Mar 2003 14:27:16 -0500 (EST) Received: from EEB174W2Kvk (unverified [157.190.81.172]) by cit.ie (Rockliffe SMTPRA 5.2.5) with SMTP id for ; Wed, 12 Mar 2003 19:28:34 +0000 Reply-To: From: "Valerie Kenneally" To: Date: Wed, 12 Mar 2003 19:29:27 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Content-Transfer-Encoding: 7bit Subject: [Sip] Via parameters Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Does anyone know where I might be able to find a complete list of all the parameters that can be appended to the Via line contents e.g. received etc. -Valerie -------------------Legal Disclaimer--------------------------------------- The above electronic mail transmission is confidential and intended only for the person to whom it is addressed. Its contents may be protected by legal and/or professional privilege. Should it be received by you in error please contact the sender at the above quoted email address. Any unauthorised form of reproduction of this message is strictly prohibited. The Institute does not guarantee the security of any information electronically transmitted and is not liable if the information contained in this communication is not a proper and complete record of the message as transmitted by the sender nor for any delay in its receipt. ---------------------------------------------------------------------------------------- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Wed Mar 12 14:36:33 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17760 for ; Wed, 12 Mar 2003 14:36:33 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2CJocM07811 for sip-archive@odin.ietf.org; Wed, 12 Mar 2003 14:50:38 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CJoGO07782; Wed, 12 Mar 2003 14:50:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CJlDO07646 for ; Wed, 12 Mar 2003 14:47:13 -0500 Received: from broadsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17578 for ; Wed, 12 Mar 2003 14:32:37 -0500 (EST) Received: from tate (host4.brodsoft.com [66.160.10.4] (may be forged)) by broadsoft.com (8.12.6) id h2CJYkM7023512; Wed, 12 Mar 2003 14:34:46 -0500 (EST) Reply-To: From: "Brett Tate" To: Subject: RE: [Sip] From/To "tag" parameter Date: Wed, 12 Mar 2003 14:37:39 -0500 Message-ID: <000c01c2e8ce$d83ae2c0$2b01a8c0@broadsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > Is it possible for a From tag and/or To tag > parameter to contain a semi-colon? It is not legal per rfc3261's "token" definition. A non escaped semi-colon used within the tag would be interpreted as a header separator. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Wed Mar 12 14:39:24 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17849 for ; Wed, 12 Mar 2003 14:39:24 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2CJrTZ07957 for sip-archive@odin.ietf.org; Wed, 12 Mar 2003 14:53:29 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CJr4O07911; Wed, 12 Mar 2003 14:53:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CJoKO07790 for ; Wed, 12 Mar 2003 14:50:20 -0500 Received: from broadsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17688 for ; Wed, 12 Mar 2003 14:35:43 -0500 (EST) Received: from tate (host4.brodsoft.com [66.160.10.4] (may be forged)) by broadsoft.com (8.12.6) id h2CJbrJ6023694; Wed, 12 Mar 2003 14:37:53 -0500 (EST) Reply-To: From: "Brett Tate" To: Subject: RE: [Sip] From/To "tag" parameter Date: Wed, 12 Mar 2003 14:40:46 -0500 Message-ID: <000d01c2e8cf$4751e960$2b01a8c0@broadsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > Is it possible for a From tag and/or To tag > parameter to contain a semi-colon? It is not legal per rfc3261's "token" definition. A non escaped semi-colon used within the tag would be interpreted as a parameter separator within the header. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Wed Mar 12 14:53:02 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18373 for ; Wed, 12 Mar 2003 14:53:02 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2CK77208956 for sip-archive@odin.ietf.org; Wed, 12 Mar 2003 15:07:07 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CK6WO08713; Wed, 12 Mar 2003 15:06:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CK3bO08539 for ; Wed, 12 Mar 2003 15:03:37 -0500 Received: from sj-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18158 for ; Wed, 12 Mar 2003 14:49:00 -0500 (EST) Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h2CJp4EY006894; Wed, 12 Mar 2003 11:51:04 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id AEX29804; Wed, 12 Mar 2003 11:45:46 -0800 (PST) Date: Wed, 12 Mar 2003 11:51:31 -0800 Subject: Re: [Sip] Draft agenda, SIP Working Group Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Dean Willis , "'Romascanu, Dan (Dan)'" , sip@ietf.org, "'Gonzalo Camarillo'" , "'Jon Peterson (jon.peterson@NeuStar.com)'" To: Kevin Lingle From: Rohan Mahy In-Reply-To: <3E6F7862.2E9E641F@cisco.com> Message-Id: <05E46F9F-54C4-11D7-BF59-0003938AF740@cisco.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Kevin, Also, once -06 is out, it would be good to see if there is interest in a MIB test at SIPit. thanks, -rohan On Wednesday, March 12, 2003, at 10:11 AM, Kevin Lingle wrote: > Dean Willis wrote: >> >> Well, I don't recall that any of the MIB authors indicated that there >> was >> any need for face time to discuss the MIB (of course, they might hve, >> and I >> might have been asleep). That, of course, may or may not be what the >> rest of >> the working group thinks. > > we (mib authors) did not ask for time on the agenda. > >> >> Do we need to discuss the MIB? Any controversial and unresolved >> issues that >> need to be talked through in the full group? >> >> It would be "nice" to move the MIB along, now that 3261 and the other >> major >> elements associated with it have basically stabilized. > > agreed. we recently published -05 revision and expect to > push out -06 because there were a few loose ends. > after passing wg lc last year w/ rev -04, we determined it > prudent to make the mib modules relevant to rfc3261. > our ability to get around do doing that work was hampered > by a number of factors. the result of that work is rev -05. > we very much wish -06 to be the last revision so the mib can > be moved along to iesg. > > besides the last call review we had last year on rev -04, > we've not had what i would consider significant review of mib > modules by the sip community over the life of the draft. > mibs are not all that interesting to most folks it seems ;) > it does give me some concern that what we are producing may or > may not have the "right stuff". > > so, it would be great if more folks could take a look at > http://ietf.org/internet-drafts/draft-ietf-sip-mib-05.txt > and provide feedback. it's still not too late ;) > > kevin > >> >> -- >> Dean >> >>> -----Original Message----- >>> From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] >>> Sent: Tuesday, March 11, 2003 7:56 PM >>> To: Dean Willis; sip@ietf.org >>> Cc: Gonzalo Camarillo; Jon Peterson >>> (jon.peterson@NeuStar.com); Rohan Mahy >>> Subject: RE: [Sip] Draft agenda, SIP Working Group >>> >>> >>> Is there any intention to include the SIP MIB on the agenda? >>> >>> Thanks, >>> >>> Dan >>> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip > > -- > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Kevin R. Lingle 919.392.2029 > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Wed Mar 12 15:07:43 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19259 for ; Wed, 12 Mar 2003 15:07:43 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2CKLnF10150 for sip-archive@odin.ietf.org; Wed, 12 Mar 2003 15:21:49 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CKLQO10121; Wed, 12 Mar 2003 15:21:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CKIPO09982 for ; Wed, 12 Mar 2003 15:18:25 -0500 Received: from iere.net.avaya.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18792 for ; Wed, 12 Mar 2003 15:03:47 -0500 (EST) Received: from iere.net.avaya.com (localhost [127.0.0.1]) by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id h2CK36h23739 for ; Wed, 12 Mar 2003 15:03:06 -0500 (EST) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id h2CK36Z23732 for ; Wed, 12 Mar 2003 15:03:06 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sip] Draft agenda, SIP Working Group Date: Wed, 12 Mar 2003 22:05:55 +0200 Message-ID: Thread-Topic: [Sip] Draft agenda, SIP Working Group Thread-Index: AcLowtvKl4v3HFHsRrCEPE0FblYvrQADEOgA From: "Romascanu, Dan (Dan)" To: "Kevin Lingle" , "Dean Willis" Cc: , "Gonzalo Camarillo" , "Jon Peterson (jon.peterson@NeuStar.com)" , "Rohan Mahy" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2CKIPO09983 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit In order to shorten the number of versions ahead, I suggest that the authors of the draft have a look (if they did not do it yet) at the MIB Review guidelines Internet-Draft http://www.ietf.org/internet-drafts/draft-ietf-ops-mib-review-guidelines-01.txt. This is not final yet, but it is quite stable, and me or whoever will be assigned to review this MIB will use it for the MIB quality review (from the SNMP / SMI point of view). Another issue is that because the MIB went through rather radical changes between versions 04 and 05, t will probably be appropriate to run this version or the next one through another WG last call. This may increase the chances to get closer to "the right stuff". Is this the plan? Thanks, Dan > -----Original Message----- > From: Kevin Lingle [mailto:klingle@cisco.com] > Sent: Wednesday, March 12, 2003 8:12 PM > To: Dean Willis > Cc: Romascanu, Dan (Dan); sip@ietf.org; 'Gonzalo Camarillo'; > 'Jon Peterson (jon.peterson@NeuStar.com)'; 'Rohan Mahy' > Subject: Re: [Sip] Draft agenda, SIP Working Group > > > Dean Willis wrote: > > > > Well, I don't recall that any of the MIB authors indicated > that there was > > any need for face time to discuss the MIB (of course, they > might hve, and I > > might have been asleep). That, of course, may or may not be > what the rest of > > the working group thinks. > > we (mib authors) did not ask for time on the agenda. > > > > > Do we need to discuss the MIB? Any controversial and > unresolved issues that > > need to be talked through in the full group? > > > > It would be "nice" to move the MIB along, now that 3261 and > the other major > > elements associated with it have basically stabilized. > > agreed. we recently published -05 revision and expect to > push out -06 because there were a few loose ends. > after passing wg lc last year w/ rev -04, we determined it > prudent to make the mib modules relevant to rfc3261. > our ability to get around do doing that work was hampered > by a number of factors. the result of that work is rev -05. > we very much wish -06 to be the last revision so the mib can > be moved along to iesg. > > besides the last call review we had last year on rev -04, > we've not had what i would consider significant review of mib > modules by the sip community over the life of the draft. > mibs are not all that interesting to most folks it seems ;) > it does give me some concern that what we are producing may or > may not have the "right stuff". > > so, it would be great if more folks could take a look at > http://ietf.org/internet-drafts/draft-ietf-sip-mib-05.txt > and provide feedback. it's still not too late ;) > > kevin > > > > > -- > > Dean > > > > > -----Original Message----- > > > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > > > Sent: Tuesday, March 11, 2003 7:56 PM > > > To: Dean Willis; sip@ietf.org > > > Cc: Gonzalo Camarillo; Jon Peterson > > > (jon.peterson@NeuStar.com); Rohan Mahy > > > Subject: RE: [Sip] Draft agenda, SIP Working Group > > > > > > > > > Is there any intention to include the SIP MIB on the agenda? > > > > > > Thanks, > > > > > > Dan > > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > -- > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > =-=-=-=-= > Kevin R. Lingle 919.392.2029 > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > =-=-=-=-= > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Wed Mar 12 15:48:17 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21586 for ; Wed, 12 Mar 2003 15:48:17 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2CL2OO13206 for sip-archive@odin.ietf.org; Wed, 12 Mar 2003 16:02:24 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CL1xO13174; Wed, 12 Mar 2003 16:01:59 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CKwAO13014 for ; Wed, 12 Mar 2003 15:58:10 -0500 Received: from rtp-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21465 for ; Wed, 12 Mar 2003 15:43:32 -0500 (EST) Received: from dingdong.cisco.com (IDENT:mirapoint@dingdong.cisco.com [64.102.17.16]) by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h2CKjXvD003287; Wed, 12 Mar 2003 15:45:34 -0500 (EST) Received: from cisco.com (klingle-ultra.cisco.com [64.102.93.47]) by dingdong.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ABS61214; Wed, 12 Mar 2003 15:41:53 -0500 (EST) Message-ID: <3E6F9C6A.A43C30A5@cisco.com> Date: Wed, 12 Mar 2003 15:45:30 -0500 From: Kevin Lingle X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" CC: Dean Willis , sip@ietf.org, Gonzalo Camarillo , "Jon Peterson (jon.peterson@NeuStar.com)" , Rohan Mahy , bwijnen@lucent.com Subject: Re: [Sip] Draft agenda, SIP Working Group References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit "Romascanu, Dan (Dan)" wrote: > > In order to shorten the number of versions ahead, I suggest that the authors of the draft have a look (if they did not do it yet) at the MIB Review guidelines Internet-Draft http://www.ietf.org/internet-drafts/draft-ietf-ops-mib-review-guidelines-01.txt. This is not final yet, but it is quite stable, and me or whoever will be assigned to review this MIB will use it for the MIB quality review (from the SNMP / SMI point of view). we did for rev -05. jean-francios mule digested the guidelines and made sure our draft was aligned. > > Another issue is that because the MIB went through rather radical changes between versions 04 and 05, t will probably be appropriate to run this version or the next one through another WG last call. This may increase the chances to get closer to "the right stuff". Is this the plan? yes. we anticipate needing another wg lc run. kevin > > Thanks, > > Dan > > > -----Original Message----- > > From: Kevin Lingle [mailto:klingle@cisco.com] > > Sent: Wednesday, March 12, 2003 8:12 PM > > To: Dean Willis > > Cc: Romascanu, Dan (Dan); sip@ietf.org; 'Gonzalo Camarillo'; > > 'Jon Peterson (jon.peterson@NeuStar.com)'; 'Rohan Mahy' > > Subject: Re: [Sip] Draft agenda, SIP Working Group > > > > > > Dean Willis wrote: > > > > > > Well, I don't recall that any of the MIB authors indicated > > that there was > > > any need for face time to discuss the MIB (of course, they > > might hve, and I > > > might have been asleep). That, of course, may or may not be > > what the rest of > > > the working group thinks. > > > > we (mib authors) did not ask for time on the agenda. > > > > > > > > Do we need to discuss the MIB? Any controversial and > > unresolved issues that > > > need to be talked through in the full group? > > > > > > It would be "nice" to move the MIB along, now that 3261 and > > the other major > > > elements associated with it have basically stabilized. > > > > agreed. we recently published -05 revision and expect to > > push out -06 because there were a few loose ends. > > after passing wg lc last year w/ rev -04, we determined it > > prudent to make the mib modules relevant to rfc3261. > > our ability to get around do doing that work was hampered > > by a number of factors. the result of that work is rev -05. > > we very much wish -06 to be the last revision so the mib can > > be moved along to iesg. > > > > besides the last call review we had last year on rev -04, > > we've not had what i would consider significant review of mib > > modules by the sip community over the life of the draft. > > mibs are not all that interesting to most folks it seems ;) > > it does give me some concern that what we are producing may or > > may not have the "right stuff". > > > > so, it would be great if more folks could take a look at > > http://ietf.org/internet-drafts/draft-ietf-sip-mib-05.txt > > and provide feedback. it's still not too late ;) > > > > kevin > > > > > > > > -- > > > Dean > > > > > > > -----Original Message----- > > > > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > > > > Sent: Tuesday, March 11, 2003 7:56 PM > > > > To: Dean Willis; sip@ietf.org > > > > Cc: Gonzalo Camarillo; Jon Peterson > > > > (jon.peterson@NeuStar.com); Rohan Mahy > > > > Subject: RE: [Sip] Draft agenda, SIP Working Group > > > > > > > > > > > > Is there any intention to include the SIP MIB on the agenda? > > > > > > > > Thanks, > > > > > > > > Dan > > > > > > > > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > Use sipping@ietf.org for new developments on the application of sip > > > > -- > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > > =-=-=-=-= > > Kevin R. Lingle 919.392.2029 > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > > =-=-=-=-= > > -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Kevin R. Lingle 919.392.2029 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Wed Mar 12 16:34:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24199 for ; Wed, 12 Mar 2003 16:34:40 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2CLmkW17794 for sip-archive@odin.ietf.org; Wed, 12 Mar 2003 16:48:46 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CLmNO17764; Wed, 12 Mar 2003 16:48:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CLhjO17560 for ; Wed, 12 Mar 2003 16:43:45 -0500 Received: from ondar.cablelabs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23793 for ; Wed, 12 Mar 2003 16:29:07 -0500 (EST) Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.8/8.12.8) with ESMTP id h2CLTdKg027699; Wed, 12 Mar 2003 14:29:39 -0700 (MST) 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" Subject: RE: [Sip] Draft agenda, SIP Working Group Date: Wed, 12 Mar 2003 14:29:39 -0700 Message-ID: Thread-Topic: [Sip] Draft agenda, SIP Working Group thread-index: AcLoOaRaUwmuZAlpTQGJVIOLtc+RyAAALA2AACjOFUA= From: "Jean-Francois Mule" To: "Romascanu, Dan (Dan)" , "Dean Willis" , Cc: "Gonzalo Camarillo" , "Jon Peterson (jon.peterson@NeuStar.com)" , "Rohan Mahy" , X-Approved: ondar Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2CLhjO17561 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Dan wrote: > Is there any intention to include the SIP MIB on the agenda? > > Thanks, > > Dan We have not requested a timeslot since draft05 is only a partial update to get the mib realign with rfc3261. I'll be at the meeting for the entire week though and we can certainly get together and do an indepth review with Kevin. Jean-Francois. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Wed Mar 12 16:51:20 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24836 for ; Wed, 12 Mar 2003 16:51:20 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2CM5R619218 for sip-archive@odin.ietf.org; Wed, 12 Mar 2003 17:05:27 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CM4mO19139; Wed, 12 Mar 2003 17:04:48 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CM1aO19050 for ; Wed, 12 Mar 2003 17:01:36 -0500 Received: from ondar.cablelabs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24702 for ; Wed, 12 Mar 2003 16:46:58 -0500 (EST) Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.8/8.12.8) with ESMTP id h2CLmUKg028523; Wed, 12 Mar 2003 14:48:30 -0700 (MST) 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" Subject: RE: [Sip] Draft agenda, SIP Working Group Date: Wed, 12 Mar 2003 14:48:29 -0700 Message-ID: Thread-Topic: [Sip] Draft agenda, SIP Working Group thread-index: AcLo3Zhwqu2t9/85TMWrwsLVJoWW0wAAEyfA From: "Jean-Francois Mule" To: "Kevin Lingle" , "Romascanu, Dan (Dan)" Cc: "Dean Willis" , , "Gonzalo Camarillo" , "Jon Peterson (jon.peterson@NeuStar.com)" , "Rohan Mahy" , X-Approved: ondar Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2CM1aO19051 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit I concur with Kevin. > "Romascanu, Dan (Dan)" wrote: > > > > In order to shorten the number of versions ahead, I suggest > that the > > authors of the draft have a look (if they did not do it yet) at the > > MIB Review guidelines Internet-Draft > > > http://www.ietf.org/internet-drafts/draft-ietf-ops-mib-review-guidelin > > es-01.txt. This is not final yet, but it is quite stable, and me or > > whoever will be assigned to review this MIB will use it > for the MIB > > quality review (from the SNMP / SMI point of view). Kevin wrote: > we did for rev -05. jean-francios mule digested the guidelines and > made sure our draft was aligned. To be precise, we did address *some* of the ops-mib-review guidelines (Bert has been showing us the way in the ipcdn wg so we took it into account as part of this draft update). What we did revise per the mib guidelines are: - boilerplate - module identity copyright - normative vs. informative references - counters: we looked at the way we use counters with Kevin - I think we're clean on inetaddress'es & rfc3291 but haven't looked back at the details That is all I believe and we may have missed a couple. Jean-Francois. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Thu Mar 13 03:42:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23972 for ; Thu, 13 Mar 2003 03:42:42 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2D8v4606739 for sip-archive@odin.ietf.org; Thu, 13 Mar 2003 03:57:04 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2D8uVO06718; Thu, 13 Mar 2003 03:56:31 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2D8qCO06523 for ; Thu, 13 Mar 2003 03:52:12 -0500 Received: from mail1.telekom.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23913 for ; Thu, 13 Mar 2003 03:37:20 -0500 (EST) Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Thu, 13 Mar 2003 09:39:15 +0100 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Thu, 13 Mar 2003 09:39:15 +0100 Message-Id: <953B9B08F98DD61183F8000347AE66011ACC72@G8PPV.blf01.telekom.de> From: "Jesske, R" To: sip@ietf.org Cc: mwatson@nortelnetworks.com, "Alexeitsev, D" Date: Thu, 13 Mar 2003 09:39:12 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] Authintification of Responses Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Dear all, RFC 3325 (Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks) is stating that: The P-Asserted-Identity header field is used among trusted SIP entities (typically intermediaries) to carry the identity of the user sending a SIP message as it was verified by authentication. From my point of view this statement includes that Requests and Responses can be verified within the SIP domain. But is this possible and described within SIP that a Response will be also verified by authenticated if needed? Background of this question is, if it is possible to interwork a P-Asserted-ID in a Response (if this could be to a connected number parameter within PSTN. The Connected number within PSTN must be a trusted number. Thank You Best Regards Roland Jesske Deutsche Telekom AG T Com Zentrale Roland Jesske, T38-12 Section T38; Signalling, Gateways and Switching Systems Am Kavalleriesand 3, 64295 Darmstadt, Germany Phone: +49 6151 83-5940 Fax: +49 6151 83-4577 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Thu Mar 13 03:56:15 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24188 for ; Thu, 13 Mar 2003 03:56:15 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2D9AbP08482 for sip-archive@odin.ietf.org; Thu, 13 Mar 2003 04:10:37 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2D9AHO08406; Thu, 13 Mar 2003 04:10:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CBDVO03054 for ; Wed, 12 Mar 2003 06:13:31 -0500 Received: from pop.mantraonline.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA29127 for ; Wed, 12 Mar 2003 05:59:03 -0500 (EST) Received: (qmail 13240 invoked from network); 12 Mar 2003 11:03:48 -0000 Received: from unknown (HELO dexceldesigns.com) ([203.145.183.43]) (envelope-sender ) by 202.56.230.15 (qmail-ldap-1.03) with SMTP for ; 12 Mar 2003 11:03:48 -0000 Message-ID: <023401c2e881$990d3500$1b010a64@DOMAIN.dexceldesigns.com> From: Jayasree Palapati To: Date: Wed, 12 Mar 2003 15:54:43 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0231_01C2E8AF.B2A0D200" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-Mailserver: Sent using PostMaster (v4.1.13) Subject: [Sip] Query on 5xx processing Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0231_01C2E8AF.B2A0D200 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi.... For a SIP proxy, on what conditions it should generate 5xx series = responses and what conditions it should forward 5xx responses? Any call flow scenarios are available? Regards, Jayasree. ------=_NextPart_000_0231_01C2E8AF.B2A0D200 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi....
 
  For a SIP proxy, on what = conditions it=20 should generate 5xx series responses and what conditions it should = forward 5xx=20 responses?
 
Any call flow scenarios are = available?
 
Regards,
Jayasree.
 
 
 

--------------------------------------------------------------
Dexcel Electronics Designs (P) Ltd., Bangalore, India
------=_NextPart_000_0231_01C2E8AF.B2A0D200-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Thu Mar 13 07:30:20 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28139 for ; Thu, 13 Mar 2003 07:30:20 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2DCiji22634 for sip-archive@odin.ietf.org; Thu, 13 Mar 2003 07:44:45 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DCiMO22621; Thu, 13 Mar 2003 07:44:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DCciO22425 for ; Thu, 13 Mar 2003 07:38:44 -0500 Received: from d12lmsgate-3.de.ibm.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28083 for ; Thu, 13 Mar 2003 07:23:45 -0500 (EST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (8.12.8/8.12.8) with ESMTP id h2DCPpEO013540 for ; Thu, 13 Mar 2003 13:25:51 +0100 Received: from d10ml001.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.12.8/NCO/VER6.5) with ESMTP id h2DCAfdF250526 for ; Thu, 13 Mar 2003 13:25:51 +0100 To: sip@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0 September 26, 2002 Message-ID: From: "Avshalom Houri" Date: Thu, 13 Mar 2003 13:40:05 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 13/03/2003 14:25:50, Serialize complete at 13/03/2003 14:25:50 Content-Type: text/plain; charset="US-ASCII" Subject: [Sip] Authenticating with LDAP Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , There seems to be a problem with implementing SIP digest authentication as described in RFC 2617 (HTTP authentication) while using LDAP servers at the back-end. The authenticating server will receive the hashed password from the client, but cannot compare this with the password in the directory, because LDAP servers do not support a uniform way for querying passwords. For example, some LDAP servers return the user's password hashed (using MD5, SHA or something else) but this hashed value can not be compared with the hashed password from the client. Even if the same hashing algorithm is used in the client and in the LDAP server it will not be possible to compare the hashed passwords since LDAP hashes only the password, while the client-supplied hash includes more info in the digest. The only way that it can be done is by getting the password in cleartext from LDAP, and do our own digest, but most LDAP servers do not allow that, not even for the directory admin. Another approach is to forward the client-supplied credentials (hashed password, etc) to the LDAP server as a SASL request (RFC 2222). According to RFC 2829 (Authentication methods for LDAP) section 4 "Implementations providing password-based authenticated access MUST support authentication using the DIGEST-MD5 SASL mechanism". Unfortunately, most LDAP servers do not follow that either. It would have been nice if SIP supported cleartext password authentication, like HTTP does, at least for TLS-encrypted connections. As I understand, it does not. The note above may be more appropriate for the SIP implementors list but it seems that there is an inherent problem that we need to solve in SIP authentication itself or assume that all LDAP servers will be modified which might be a too optimistic assumption. Avshalom _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Thu Mar 13 10:59:06 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06639 for ; Thu, 13 Mar 2003 10:59:05 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2DGDaC07711 for sip-archive@odin.ietf.org; Thu, 13 Mar 2003 11:13:36 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DGD6O07685; Thu, 13 Mar 2003 11:13:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DG9fO07467 for ; Thu, 13 Mar 2003 11:09:41 -0500 Received: from znsgs01r.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06461 for ; Thu, 13 Mar 2003 10:54:39 -0500 (EST) Received: from znsgy0k8.europe.nortel.com (znsgy0k8.europe.nortel.com [47.165.24.67]) by znsgs01r.nortelnetworks.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2DFuk716609; Thu, 13 Mar 2003 15:56:47 GMT Received: from zwcwc012.europe.nortel.com ([47.160.46.124]) by znsgy0k8.europe.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id GR68LH8X; Thu, 13 Mar 2003 15:56:41 -0000 Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 13 Mar 2003 15:55:36 -0000 Message-ID: X-Sybari-Space: 00000000 00000000 00000000 From: "Mark Watson" To: "'Jesske, R'" , sip@ietf.org Cc: "Alexeitsev, D" Date: Thu, 13 Mar 2003 15:55:33 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2E978.FB1CC34E" Subject: [Sip] RE: Authintification of Responses Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , 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_01C2E978.FB1CC34E Content-Type: text/plain; charset="iso-8859-1" Roland, The P-Asserted-Identity can be used in responses. The extract you quote was intended to mean that the 'identity of the user' was verified by authentication, rather than the 'message' itself being verified by authentication (I guess the 'it' in that extract could be ambiguous). It doesn't say how or when the authentication was carried out. For example, if a proxy has authenticated a user by some secure means and then later if the same proxy can securely determine that a particular response came from the same user, THEN that proxy can use the result of the initial authentication to insert a P-Asserted-Identity in the later response. This could be achieved, for example, by use of some kind of integrity protection on the UA-Proxy link. As to whether you could interwork this P-Asserted-Identity to the Connected Number within the PSTN, this depends on whether the rules of your particular Trust Domain for Asserted Identity (in terms of what it means for a number to be 'trusted') match the rules within the PSTN (potentially the particular national PSTN) for Connected Number. Certainly it is possible and conceivable for the rules to match - and this would motivate including a protocol mapping within any interworking specification you might happen to be writing - but it should be clear that (as with CLI), whether this mapping takes place in a given situation depends on the policies of the Trust Domains. ...Mark > -----Original Message----- > From: Jesske, R [mailto:R.Jesske@telekom.de] > Sent: 13 March 2003 08:39 > To: sip@ietf.org > Cc: Watson, Mark [MOP:EP10:EXCH]; Alexeitsev, D > Subject: Authintification of Responses > > > Dear all, > RFC 3325 (Private Extensions to the Session Initiation > Protocol (SIP) for Asserted Identity within Trusted Networks) > is stating that: > > The P-Asserted-Identity header field is used among trusted SIP > entities (typically intermediaries) to carry the identity of the user > sending a SIP message as it was verified by authentication. > > From my point of view this statement includes that Requests > and Responses can be verified within the SIP domain. But is > this possible and described within SIP that a Response will > be also verified by authenticated if needed? > > Background of this question is, if it is possible to > interwork a P-Asserted-ID in a Response (if this could be to > a connected number parameter within PSTN. The Connected > number within PSTN must be a trusted number. > > > Thank You > > Best Regards > > Roland Jesske > > > > > Deutsche Telekom AG > T Com Zentrale > Roland Jesske, T38-12 > Section T38; Signalling, Gateways and Switching Systems > Am Kavalleriesand 3, 64295 Darmstadt, Germany > Phone: +49 6151 83-5940 > Fax: +49 6151 83-4577 > > > > > ------_=_NextPart_001_01C2E978.FB1CC34E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Authintification of Responses

Roland,

The P-Asserted-Identity can be used in = responses.

The extract you quote was intended to mean that the = 'identity of the user' was verified by authentication, rather than the = 'message' itself being verified by authentication (I guess the 'it' in = that extract could be ambiguous). It doesn't say how or when the = authentication was carried out.

For example, if a proxy has authenticated a user by = some secure means and then later if the same proxy can securely = determine that a particular response came from the same user, THEN that = proxy can use the result of the initial authentication to insert a = P-Asserted-Identity in the later response.

This could be achieved, for example, by use of some = kind of integrity protection on the UA-Proxy link.

As to whether you could interwork this = P-Asserted-Identity to the Connected Number within the PSTN, this = depends on whether the rules of your particular Trust Domain for = Asserted Identity (in terms of what it means for a number to be = 'trusted') match the rules within the PSTN (potentially the particular = national PSTN) for Connected Number.

Certainly it is possible and conceivable for the = rules to match - and this would motivate including a protocol mapping = within any interworking specification you might happen to be writing - = but it should be clear that (as with CLI), whether this mapping takes = place in a given situation depends on the policies of the Trust = Domains.

...Mark


> -----Original Message-----
> From: Jesske, R [mailto:R.Jesske@telekom.de]
> Sent: 13 March 2003 08:39
> To: sip@ietf.org
> Cc: Watson, Mark [MOP:EP10:EXCH]; Alexeitsev, = D
> Subject: Authintification of Responses
>
>
> Dear all,
> RFC 3325 (Private Extensions to the Session = Initiation
> Protocol (SIP) for Asserted Identity within = Trusted Networks)
> is stating that:
>
> The P-Asserted-Identity header field is used = among trusted SIP
> entities (typically intermediaries) to carry = the identity of the user
> sending a SIP message as it was verified by = authentication.
>
> From my point of view this statement includes = that Requests
> and Responses can be verified within the SIP = domain. But is
> this possible and described within SIP that a = Response will
> be also verified by authenticated if = needed?
>
> Background of this question is, if it is = possible to
> interwork a P-Asserted-ID in a Response (if = this could be to
> a connected number parameter within PSTN. The = Connected
> number within PSTN must be a trusted = number.
>
>
> Thank You
>
> Best Regards
>
> Roland Jesske
>
>
>
>
> Deutsche Telekom AG
> T Com Zentrale
> Roland Jesske, T38-12
> Section T38; Signalling, Gateways and Switching = Systems
> Am Kavalleriesand 3, 64295 Darmstadt, = Germany
> Phone:  +49 6151 83-5940
> Fax:    +49 6151 83-4577
>  <mailto:r.jesske@telekom.de>
>
>
>
>

------_=_NextPart_001_01C2E978.FB1CC34E-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Thu Mar 13 11:02:21 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06774 for ; Thu, 13 Mar 2003 11:02:21 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2DGGqU07903 for sip-archive@odin.ietf.org; Thu, 13 Mar 2003 11:16:52 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DGGKO07813; Thu, 13 Mar 2003 11:16:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DGAVO07584 for ; Thu, 13 Mar 2003 11:10:31 -0500 Received: from ihemail1.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06508 for ; Thu, 13 Mar 2003 10:55:29 -0500 (EST) Received: from uk0006exch001h.wins.lucent.com (h135-86-145-57.lucent.com [135.86.145.57]) by ihemail1.firewall.lucent.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2DFvcf28542 for ; Thu, 13 Mar 2003 10:57:39 -0500 (EST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2653.19) id ; Thu, 13 Mar 2003 15:57:37 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB00439EC63@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "'Jesske, R'" , sip@ietf.org Cc: mwatson@nortelnetworks.com, "Alexeitsev, D" Subject: RE: [Sip] Authintification of Responses Date: Thu, 13 Mar 2003 15:57:36 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , The P-Asserted-Identity is generated by a trusted entity. In order to perform this action, the trusted entity must know who the user is, hence the concept of authentication. However that authentication does not need to be performed over each individual message. For example, in 3GPP, that authentication is performed at the time of sending a REGISTER from that user, and subsequent requests and responses are sent using the agreed security mechanism (see RFC 3329), and therefore the P-Asserted-Identity of the destination user can be added by the trusted proxy associated with that destination user to any response (or request) generated by that destination user. For the PSTN interworking case, we effectively have two trust domains. One in the ISUP network and the other in the SIP network. Assuming that equivalent levels of trust exist between those two trust domains, which entirely within a public network environment can be assumed, then a Connected number on the BICC / ISUP side can result in a P-Asserted-Identity in a SIP response. Keith Drage Lucent Technologies Tel: +44 1793 776249 Email: drage@lucent.com > -----Original Message----- > From: Jesske, R [mailto:R.Jesske@telekom.de] > Sent: 13 March 2003 08:39 > To: sip@ietf.org > Cc: mwatson@nortelnetworks.com; Alexeitsev, D > Subject: [Sip] Authintification of Responses > > > Dear all, > RFC 3325 (Private Extensions to the Session Initiation > Protocol (SIP) for Asserted Identity within Trusted Networks) > is stating that: > > The P-Asserted-Identity header field is used among trusted SIP > entities (typically intermediaries) to carry the identity of the user > sending a SIP message as it was verified by authentication. > > From my point of view this statement includes that Requests > and Responses can be verified within the SIP domain. But is > this possible and described within SIP that a Response will > be also verified by authenticated if needed? > > Background of this question is, if it is possible to > interwork a P-Asserted-ID in a Response (if this could be to > a connected number parameter within PSTN. The Connected > number within PSTN must be a trusted number. > > > Thank You > > Best Regards > > Roland Jesske > > > > > Deutsche Telekom AG > T Com Zentrale > Roland Jesske, T38-12 > Section T38; Signalling, Gateways and Switching Systems > Am Kavalleriesand 3, 64295 Darmstadt, Germany > Phone: +49 6151 83-5940 > Fax: +49 6151 83-4577 > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Fri Mar 14 02:52:22 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18410 for ; Fri, 14 Mar 2003 02:52:22 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2E87BG21713 for sip-archive@odin.ietf.org; Fri, 14 Mar 2003 03:07:11 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2E86OO21412; Fri, 14 Mar 2003 03:06:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2E7wPO21092 for ; Fri, 14 Mar 2003 02:58:25 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18338 for ; Fri, 14 Mar 2003 02:43:04 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.54]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h2E7jJJD017492 for ; Fri, 14 Mar 2003 02:45:19 -0500 (EST) Message-ID: <3E71888A.2030301@dynamicsoft.com> Date: Fri, 14 Mar 2003 02:45:14 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] changes in caller prefs Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Folks, As you may have seen, I have submitted an update to the caller prefs spec. A lot of work went into this draft since the last rev. There are a lot of changes, which are summarized below. Generally speaking, the reasons for many of these changes were to make caller prefs functional for many of the use cases that we are considering. The reason that the draft took so long is that it still cannot cover all of them, and I believe significantly more complexity would be needed to support all of them. However, I have concluded that we should simply declare those out of scope for now, primarily because we dont really know what people are going to use caller prefs for. We need to gain more experience with it. The specific cases which arent well covered at this point are those where you wish to preferentially route to a UA that has declared a capability that is the best explicit match for the callers preference. For example, if the caller asks for audio, video, messaging, the call would be routed first to a UA that said it did audio and video (but said nothing about messaging), and second to a UA that said it did audio (but said nothign about messaging or video). If we agree that this feature is out of scope, I believe caller prefs as written is done, and there are no open issues. A lot of good fixes went into this version, and its time to declare victory. I'll be talking more about this during the ietf meeting. Changes: * added Paul K as co-author to acknowledge his contributions to the work. * we always had this problem that there was no way to determine which contact parameters were caller prefs. Enough folks have complained that I put a solution in place. The parameters defined in this spec itself can appear as they are. However, any other parameters (including ones registered already) have to appera with a leading +. So, if you invent a new media tag foo, you would use it in the contact params thusly: Contact: ;audio="TRUE";+foo="FALSE" * eliminated the Require-Contact header field. Replaced it with the new require parameter of the Accept-Contact header field. * added a weighting to the proxy computations, so that contacts that are a better match to the accept-contact header result in a higher q-value. * aligned the "mime" media type feature tags around the SDP media types instead. Thus, the values defined include audio, video, application, data and control. * added text to deal with the possible future definition of new SDP media types: If a new SDP media type were to be defined, such as ``message'', a new feature tag registration SHOULD be created for it. The name of the feature tag MUST equal that of the media type, unless there is an unlikely naming collision between the new media type and an existing feature tag registration. As a result of this, implementations can safely contruct caller preferences and callee capabilities for the new media type before it is registered, as long as there is no naming conflict. * added the new "explicit" parameter to the Accept-Contact header field. It is used to signal that a contact must match explicitly. * changed the "voicemail" tag to "msgserver" since the voicemail term is voice specific. * the q-value parameter can now appear anywhere in the header field value; it need not occur after the feature tags, as before. * allow the feature tag to appaer with no value. i.e.,: Accept-Contact: *;video;audio when present in this form, it means ="TRUE". * allow for the value to be a comma separate lists of numerics and booleans, not just tokens, as previously. However, you still can only have a single string value. * you can negate booleans and numerics now (used to be only token equalities could be negated) * fixed the syntax bug which would result in quoted strings being double-quoted. * changed the range syntax to use a colon, and removed the useless "R" * numbers were formerly represented in fractional form (i.e., 3/4) instead of decimal (0.75). THis was just because thats how rfc2533 represents them. Several folks complained, so I changed it to a decimal form. The section on mapping to rfc2533 describes the conversion between the two. Of course, in practice, it is probably never needed to convert. * Changed the syntax of the feature tag itself, adding support for escaping and the + sign * Allowed for generic-param in Accept and Reject contact, to allow for future extensions. * Mandated that, when numeric parameters are present in a feature param, they be representable as an ANSI C double. * Changed the title to reflect sip-guidlines guidance * changed the header table column for proxies from r to ar. THis means a proxy can add or modify a value. Discussion of this is added in the proxy processing section. Proxies can't remove or modify header field values because of s/mime, and this is pointed out. * removed implicit preferences for media, languages and priority per list discussion. * added a note saying that you are now allowed to express explicit preferences for methods, event packages or schemes not defined in ietf standards track protocols. * added UA processing of OPTIONS. The contact header in the 200 OK to options can contain feature parameters. * added isfocus parameter. This is needed for the conferencing work. It seemed easier to add it in here than to issue a separate RFC just to register it. * if application of caller prefs results in the elimination of all registered contacts, the algorithm is re-run, but this time, any implict preferences are not at the require strength. This is as per list discussion. * added an extensive example to the proxy matching section * note that if a UA registers against two separate addresses-of-record, and the contacts registered for each have different capabilities, a UA MUST use different URIs in each registration. This is so that the UA can uniquely determine the feature set that is associated with the request URI of an incoming request. * updated table 2/3 to also include MESSAGE. * added a nice figure to explain the proxy matching operation * added an example service that is enabeld by called prefs to help motivate interest. * clients registering caller prefs params SHOULD use sips for privacy services, and callers SHOULD use sips for integrity protection (iesg wants to see baseline mechanisms for addressign all threats described in security considerations) * Previously, the uri-domain and uri-user feature tags had very special processing. Only the UA would compute them (they were not real feature tags) for registered contacts, and apply them to any Accept or Reject-Contact. This was to solve the problem previously solved by the "only=true" flag. Namely, a proxy couldn't reject a contact because of a mismatch in the URI, since a downstream forwarding operation might actually route to that contact. As it turns out, this problem is not specific to the URI parameters. Generally, it is only safe to compute caller preferences when they refer to a URI that is a UA, as opposed to an AOR. So, several changes were made. First, uri-domain and uri-user would made full feature tags. Like all the others, they are explicitly registered by a UA. A UA can now opt to register NO feature parameters for a contact. Such contacts are "immune" from caller preferences processing. Thus, when a UA registers an AOR, it includes no feature parameters. When it registers a contact for a UA, it includes feature parameters. It can include the uri-user and uri-domain parameters. They must be explicit now. These receive no special processing at the proxy. The only "exception" is that in Accept or Reject-Contact, they can appear as parameters, or appear as the URI itself. To some degree, that makes the URI redundant, but I retained it for backwards compatibility. * special treatment of the schemes parameter by the proxy has been removed. Formerly, if it wasnt explicitly indicated, the proxy computed an implicit schemes parameter. No longer, for the same problem as above. * implicit preferences are only computed by the proxy if no explicit preferences at all were provided. This eliminates the need for the proxy to figure out how to combine the explicit and implicit preferences. Text was added the the UA section RECOMMENDing inclusion of method and event preferences, and to do so by adding a term to all existing A-C predicates. * UA registration procedures explicitly call out the handling of contacts that are not UA instances. There is a good discussion on the meaning of registering an AOR, and how to associate feature parameters with it. * the spec was unclear about exactly WHEN in the UAS processing steps the caller preferences checks are done. It actually matters. It needs to be done after authentication/authorization, but before the rest of 8.2.1 of rfc3261. Also, the spec didnt state what to do if there was or wasnt a match. If there is no match, send 480. If there was a match, continue with request processing. * the spec had evolved over time to an inconsistent usage of the schemes feature parameter. There are two interpretations. One is "this is the scheme of the URI associated with my UA", making it a peer of the uri-domain and uri-user parameters. Another interptation is "I know how to handle redirects to URIs of these schemes, or how to process them if they were entered on my UI". The desired interpretation is the latter. That has been clarified, and usage made consistent with this view throughout the spec. * clarify that quoted strings in rfc2533 are matched using CS matching, and tokens using CI. * provided a warning that the "application" feature tag is not that useful in genreal. * clarified that the priority feature tag indicates that a UA can support calls of a certain priority and higher. * added sip-extensions feature tag * Accept-Contact and Reject-Contact used to have a URI or a * as the value, along with the feature params. With the explicit uri-user and uri-domain params, continued use of the URI introduced redundancy in the header, and also made the text more confusing. So, it has been removed. The two headers ALWAYS have a value of *, followed by the feature params, which can include the uri-user and uri-domain if the caller wants to express preferences on those. The * itself can't be removed, since the sip guidelines spec mandates that a token be present in the value. * added some guidance on proper redirection using caller prefs. If you redirect and include q-values that were the result of caller prefs modification, the redirect can't include the caller prefs feature parameters. If they did, the upstream proxy would apply the same caller prefs operation again! * substantial rework of the algorithm used to combine the various q-values involved. Now, a specific algorithm is provided, engineered to have particular properties. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Fri Mar 14 10:24:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29031 for ; Fri, 14 Mar 2003 10:24:59 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2EFdvs18574 for sip-archive@odin.ietf.org; Fri, 14 Mar 2003 10:39:57 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EFcgO18482; Fri, 14 Mar 2003 10:38:42 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EFZgO17601 for ; Fri, 14 Mar 2003 10:35:42 -0500 Received: from znsgs01r.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28839 for ; Fri, 14 Mar 2003 10:20:12 -0500 (EST) Received: from znsgy0k8.europe.nortel.com (europem01.nt.com [47.165.24.67]) by znsgs01r.nortelnetworks.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2EFMLn11865 for ; Fri, 14 Mar 2003 15:22:21 GMT Received: from zwcwc012.europe.nortel.com ([47.160.46.124]) by znsgy0k8.europe.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id GR68319R; Fri, 14 Mar 2003 15:22:21 -0000 Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 14 Mar 2003 15:21:10 -0000 Message-ID: X-Sybari-Space: 00000000 00000000 00000000 From: "Mark Watson" To: "'sip@ietf.org'" Date: Fri, 14 Mar 2003 15:21:06 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2EA3C.EEBFFE94" Subject: [Sip] S/MIME signatures Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This 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_01C2EA3C.EEBFFE94 Content-Type: text/plain; charset="iso-8859-1" All, RFC3261, 23.3 says: "multipart/signed" MUST be used only with CMS detached signatures. But according to RFC2633 (S/MIME) "multipart/signed" is only used with detached signatures anyway. From RFC2633, Section 3.4.3: "The multipart/signed MIME type has two parts. The first part contains the MIME entity that is signed; the second part contains the "detached signature" CMS SignedData object in which the encapContentInfo eContent field is absent." So, what is the intention of the statement from RFC3261 ? Is it meant instead that the case where the content is encapsulated in the CMS SignedData is NOT allowed in SIP ? This would use "application/pkcs7-mime", not "multipart/signed". Regards...Mark ------_=_NextPart_001_01C2EA3C.EEBFFE94 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable S/MIME signatures

All,

RFC3261, 23.3 says:

        "multipart/signed" MUST be used only with CMS = detached signatures.

But according to RFC2633 (S/MIME) = "multipart/signed" is only used with detached signatures = anyway. From RFC2633, Section 3.4.3:

   "The multipart/signed MIME type has = two parts. The first part contains the
   MIME entity that is signed; the second = part contains the "detached
   signature" CMS SignedData object = in which the encapContentInfo
   eContent field is absent."

So, what is the intention of the statement from = RFC3261 ?

Is it meant instead that the case where the content = is encapsulated in the CMS SignedData is NOT allowed in SIP ? This = would use "application/pkcs7-mime", not = "multipart/signed".

Regards...Mark

------_=_NextPart_001_01C2EA3C.EEBFFE94-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Fri Mar 14 10:36:52 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29578 for ; Fri, 14 Mar 2003 10:36:52 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2EFppm19302 for sip-archive@odin.ietf.org; Fri, 14 Mar 2003 10:51:51 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EFfGO18649; Fri, 14 Mar 2003 10:41:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EFaxO17648 for ; Fri, 14 Mar 2003 10:36:59 -0500 Received: from znsgs01r.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28907 for ; Fri, 14 Mar 2003 10:21:28 -0500 (EST) Received: from znsgy0k8.europe.nortel.com (znsgy0k8.europe.nortel.com [47.165.24.67]) by znsgs01r.nortelnetworks.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2EFNbn12009 for ; Fri, 14 Mar 2003 15:23:38 GMT Received: from zwcwc012.europe.nortel.com ([47.160.46.124]) by znsgy0k8.europe.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id GR683FF2; Fri, 14 Mar 2003 15:23:37 -0000 Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 14 Mar 2003 15:22:32 -0000 Message-ID: X-Sybari-Space: 00000000 00000000 00000000 From: "Mark Watson" To: "'sip@ietf.org'" Date: Fri, 14 Mar 2003 15:22:25 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2EA3D.84998B38" Subject: [Sip] S/MIME & Selective Anonymity Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This 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_01C2EA3D.84998B38 Content-Type: text/plain; charset="iso-8859-1" All, Firstly, apologies if this has all been discussed before - I couldn't find a searchable version of the archive to check. RFC3261 describes the use of S/MIME to provide selective anonymity in Section 23.4.3. This is the case where I wish to establish a session and remain anonymous to all but the intended recipient of the session (and any proxies I authenticate with, of course). The UAC puts 'anonymous' in the From: field and includes an encrypted message/sip MIME body containing the real From value. The text then seems to recommend that the result is signed by the UAC: "In order to provide end-to-end integrity, encrypted "message/sip" MIME bodies SHOULD be signed by the sender. This creates a "multipart/signed" MIME body that contains an encrypted body and a signature, both of type "application/pkcs7-mime". [BTW, this last bit seems to be in error since the signature part should be "application/pkcs7-signature", unless I have missed something.] But now it appears to be possible to identify the sender based on the SignerIdentifier in the signerInfo of the CMS SignedData message or the subjectAltName of the certificate, which according to 23.2 MUST be included. Have I missed something here ? Wouldn't it be better for the UAC to sign the message/sip MIME body first, and then encrypt ? I understand that an S/MIME compliant receiver should accept this, but should this be described in the SIP context ? Even if it were hard to identify a user based just on the SignerIdentifier, it would at least be possible to recognise multiple requests from the same user as indeed being from the same user, which is also a privacy breach. Regards...Mark ------_=_NextPart_001_01C2EA3D.84998B38 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable S/MIME & Selective Anonymity

All,

Firstly, apologies if this has all been discussed = before - I couldn't find a searchable version of the archive to = check.

RFC3261 describes the use of S/MIME to provide = selective anonymity in Section 23.4.3. This is the case where I wish to = establish a session and remain anonymous to all but the intended = recipient of the session (and any proxies I authenticate with, of = course).

The UAC puts 'anonymous' in the From: field and = includes an encrypted message/sip MIME body containing the real From = value.

The text then seems to recommend that the result is = signed by the UAC:

   "In order to provide end-to-end = integrity, encrypted "message/sip"
   MIME bodies SHOULD be signed by the = sender.  This creates a
   "multipart/signed" MIME body = that contains an encrypted body and a
   signature, both of type = "application/pkcs7-mime".

[BTW, this last bit seems to be in error since the = signature part should be "application/pkcs7-signature", = unless I have missed something.]

But now it appears to be possible to identify the = sender based on the SignerIdentifier in the signerInfo of the CMS = SignedData message or the subjectAltName of the certificate, which = according to 23.2 MUST be included.

Have I missed something here ?

Wouldn't it be better for the UAC to sign the = message/sip MIME body first, and then encrypt ?  I understand that = an S/MIME compliant receiver should accept this, but should this be = described in the SIP context ?

Even if it were hard to identify a user based just on = the SignerIdentifier, it would at least be possible to recognise = multiple requests from the same user as indeed being from the same = user, which is also a privacy breach.

Regards...Mark


 

------_=_NextPart_001_01C2EA3D.84998B38-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Fri Mar 14 11:01:46 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00544 for ; Fri, 14 Mar 2003 11:01:46 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2EGGjR21514 for sip-archive@odin.ietf.org; Fri, 14 Mar 2003 11:16:45 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EG7OO20716; Fri, 14 Mar 2003 11:07:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EFxrO19745 for ; Fri, 14 Mar 2003 10:59:53 -0500 Received: from hoemail1.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29960 for ; Fri, 14 Mar 2003 10:44:23 -0500 (EST) Received: from uk0006exch001h.wins.lucent.com (h135-86-145-57.lucent.com [135.86.145.57]) by hoemail1.firewall.lucent.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2EFkWu26043 for ; Fri, 14 Mar 2003 10:46:32 -0500 (EST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2653.19) id ; Fri, 14 Mar 2003 15:46:31 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB00439EC6D@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "'sip@ietf.org'" Cc: "'jari.arkko@ericsson.com'" , "'vesa.torvinen@ericsson.fi'" , "'Gonzalo.Camarillo@ericsson.com'" , "'aki.niemi@nokia.com'" , "'tao.haukka@nokia.com'" Date: Fri, 14 Mar 2003 15:46:29 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] Some comments on RFC 3329 (Security Mechanism Agreement for the S ession Initiation Protocol) Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , In looking at this RFC we detect some issues that ought to be resolved even though this is a published RFC. There is also an issue that is raised with regard to RFC 3261. 1) Section 2.6, table 1. The Security-Verify header is not included in the PRACK according to the table. It is our belief that the header should be applicable to all methods except ACK and CANCEL, where we agree that it makes no sense. 2) Section 2.3.1, 9th paragraph. In relation to the above comment, this text states: All the subsequent SIP requests sent by the client to that server SHOULD make use of the security mechanism initiated in the previous step. These requests MUST contain a Security-Verify header field that mirrors the server's list received previously in the Security- Server header field. These requests MUST also have both a Require and Proxy-Require header fields with the value "sec-agree". This text should explicitly exclude the ACK and CANCEL requests. Something along the lines of: All the subsequent SIP requests except the ACK request and the CANCEL request sent by the client to that server... 3) Section 6.4 defines the new status code 494 (By the way what is the distinction between the term "status code" and "response code" - RFC 3261 seems to use both interchangeably). Unlike other codes in RFC 3261, this RFC does not define any semantic meaning to the status code. While obviously we should not define user action on receiving status codes, one idea we would like to convey is that any recovery by the user caused by a 494 being sent in response to a Security-Verify header check, specified in 2.3.1 as follows: The server can proceed processing a particular request if, and only if, the list was not modified. If modification of the list is detected, the server MUST respond to the client with a 494 (Security Agreement Required) response. This response MUST include the server's unmodified list of supported security mechanisms. If the list was not modified, and the server is a proxy, it MUST remove the "sec-agree" value from both the Require and Proxy-Require header fields, and then remove the header fields if no values remain. should be appropriate to the security mechanism that is being agreed, rather than a matter of sticking the appropriate headers in the next method to be sent. Thus if the security architecture used specifies doing the security agreement over the REGISTER method, then that is the method that must be used for the recovery. Some extra words in 6.4 to this effect would be useful. I would suggest something along the lines of: "The server received a request which either requires a security agreement to be made, or the security agreement indicated did not match that already made. In order to continue, the UAC will need to make a new security agreement using requests appropriate to the security mechanism for which agreement is made. Any existing dialogs can have been terminated as a result of the loss of the security agreement." 4) General. The document is inconsistent in its use of the Require and Proxy-Require headers compared to RFC 3261. As a result I believe changes are probably required to both documents. The current situation in RFC 3261 is that proxies use the Proxy-Require header, and that UAs user the Require header. Neither entity is allowed to remove items from either header. RFC 3329 currently seems to allow proxies to read and react to contents of the Require header, and both Proxy-Require and Require headers have the sec-agree option-tags removed by a proxy. What I believe should happen is that RFC 3261 should be modified to specify "d" for proxies in the table that Jonathan dislikes - I mean table 2 and 3 of RFC 3261 for both these headers. Text concerning these headers should be modifed such that where a proxy is reacting and providing capabilities in accordance with the extension/application described in the Proxy-Require header, then the application/extension can define procedures for the deletion of option-tags relating to that extension/application in both the Require and Proxy-Require headers. Unless this is defined in the extension/application, then the proxy must not remove option-tags. What needs to change in RFC 3329 is that proxy procedures should react only to the Proxy-Require header contents, and UAs should react only to Require header contents, strictly in accordance with RFC 3261. The procedures currently define the modification of Proxy-Require and Require headers for this extension. regards Keith Keith Drage Lucent Technologies Tel: +44 1793 776249 Email: drage@lucent.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Fri Mar 14 13:44:49 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06750 for ; Fri, 14 Mar 2003 13:44:49 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2EIxpA32278 for sip-archive@odin.ietf.org; Fri, 14 Mar 2003 13:59:51 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EIwXO32221; Fri, 14 Mar 2003 13:58:33 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EIsXO32077 for ; Fri, 14 Mar 2003 13:54:33 -0500 Received: from dyn-tx-arch-crash.dfw.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06124 for ; Fri, 14 Mar 2003 13:39:00 -0500 (EST) Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h2EIfA913790 for ; Fri, 14 Mar 2003 12:41:10 -0600 From: Robert Sparks To: sip@ietf.org Content-Type: text/plain Message-Id: <1047667073.1019.303.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 14 Mar 2003 12:37:53 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] sip bugzilla instance Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit The working group's bugzilla instance has been temporarily shifted to http://bugs.sipit.net/ I'll send a note when it returns to sipwg.org. Sorry for the inconvenience, RjS _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Fri Mar 14 15:05:11 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11350 for ; Fri, 14 Mar 2003 15:05:11 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2EKKFL06286 for sip-archive@odin.ietf.org; Fri, 14 Mar 2003 15:20:15 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EKJkO06221; Fri, 14 Mar 2003 15:19:46 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EKGMO06119 for ; Fri, 14 Mar 2003 15:16:22 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11040 for ; Fri, 14 Mar 2003 15:00:47 -0500 (EST) Received: from dynamicsoft.com ([63.113.47.242]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h2EK32JD017826 for ; Fri, 14 Mar 2003 15:03:03 -0500 (EST) Message-ID: <3E723571.5060300@dynamicsoft.com> Date: Fri, 14 Mar 2003 15:02:57 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: sip@ietf.org Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-mib-05.txt References: <200303071154.GAA21633@ietf.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I have begun to look at the mib a bit, and I am a bit concerned that there is far too much information exposed, in terms of statistics, at least. I have to apologize for raising this so late in the game, but it is only recently that my day job has brought me into OAMP areas. One item that struck me as particularly demanding on an implementation is the sipTransactionTable. There is a huge amount of work in maintaining this table. I really doubt people will want to implement it. My suspicion is that this kind of information will normally be logged by implementations, and when you need it, its not in real time, but rather through some kind of offline analysis of the logs. Generally, it is my perception that MIB status variables are primarily aimed at fault and performance analysis. I dont see how a full list of each transaction, with the call-id, cseq and all, supports either aim. Thanks, Jonathan R. Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Session Initiation Protocol Working Group of the IETF. > > Title : Management Information Base for Session Initiation > Protocol > Author(s) : K. Lingle, J. Maeng, J. Mule, D. Walker > Filename : draft-ietf-sip-mib-05.txt > Pages : 97 > Date : 2003-3-6 > > This memo defines a portion of the Management Information Base (MIB) > for use with network management protocols in the Internet community. > In particular, it describes a set of managed objects that are used > to manage Session Initiation Protocol (SIP) entities, which include > User Agents, Proxy servers, Redirect servers and Registrars. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-sip-mib-05.txt > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body of the message. > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-sip-mib-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-mib-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. > -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Sun Mar 16 11:18:47 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28553 for ; Sun, 16 Mar 2003 11:18:47 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2GGYif07473 for sip-archive@odin.ietf.org; Sun, 16 Mar 2003 11:34:44 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GGX5O07386; Sun, 16 Mar 2003 11:33:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DB6mO15477 for ; Thu, 13 Mar 2003 06:06:48 -0500 Received: from mail.tssg.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26329 for ; Thu, 13 Mar 2003 05:51:54 -0500 (EST) Received: from boolard (unknown [10.37.1.56]) by mail.tssg.org (Postfix) with SMTP id 2722C1806B for ; Thu, 13 Mar 2003 10:48:28 +0000 (GMT) From: "Shane McCormack" To: "Sip@Ietf. Org" Date: Thu, 13 Mar 2003 10:58:24 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: Content-Transfer-Encoding: 7bit Subject: [Sip] SUBSCRIBE for Geographical Coordinates Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, Im just wondering how to return geographical coordinates for a sip user agent. The Scenario would be SIP Location enabled handsets(GPS?). Would you use an event notification package and if so would the requirements be simiilar to subscribing to presence events only returning a geographical coordinate on a specific time interval. Any feedback would be helpful. Regards ShaneShane McCormack Research Assistant, TSSG, Confederation House, Waterford Business Park, Cork Road, Waterford, Co. Waterford. Phone: +353 51 302927 Fax: +353 51 302901 Mobile: +353 87 9955505 http://www.tssg.org MSN: mccormackshane@hotmail.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Mon Mar 17 11:22:09 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18802 for ; Mon, 17 Mar 2003 11:22:09 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2HGcZM12940 for sip-archive@odin.ietf.org; Mon, 17 Mar 2003 11:38:35 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2HGbvO12909; Mon, 17 Mar 2003 11:37:57 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2HGXgO11991 for ; Mon, 17 Mar 2003 11:33:42 -0500 Received: from sunserver1.ietf56.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18645 for ; Mon, 17 Mar 2003 11:16:44 -0500 (EST) Received: from ca-69-236.wired.ietf56.ietf.org ([130.129.69.236] helo=BPenfield) by sunserver1.ietf56.ietf.org with smtp (Exim 4.12) id 18uxJf-0001MW-00; Mon, 17 Mar 2003 11:18:23 -0500 Message-ID: <000401c2eca0$e60f2570$ec458182@BPenfield> From: "Bob Penfield" To: Cc: "Henning Schulzrinne" , Date: Mon, 17 Mar 2003 11:07:39 -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.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Subject: [Sip] use of 420 in draft-polk-sip-resource-02.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I have a comment on the use of the 420 response in the resource priority draft. In section 4.2, it says the 420 (Extension Required) response is used if the SIP element does not understand the "Resource-Priority" tag or it does not understand the namespace or priority value. I believe this is in conflict with the use of the 417 response described in section 4.1 and the proper use of 420 as described in RFC 3261. The 420 response should only be used if it does not understand the feature tag. The 417 response (as described in section 4.1) should be used when it does not understand the namespace or priority value. If 420 was only used as described in 3261, the Accept-Resource-Priority header would not appear in a 420 response. cheers, (-:bob Robert F. Penfield Chief Software Architect Acme Packet, Inc. 130 New Boston Street Woburn, MA 01801 bpenfield@acmepacket.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Mon Mar 17 16:42:46 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03043 for ; Mon, 17 Mar 2003 16:42:46 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2HLxJ105763 for sip-archive@odin.ietf.org; Mon, 17 Mar 2003 16:59:19 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2HLwgO05732; Mon, 17 Mar 2003 16:58:42 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2HDCoO31533 for ; Mon, 17 Mar 2003 08:12:50 -0500 Received: from bharatmail.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12310 for ; Mon, 17 Mar 2003 07:55:55 -0500 (EST) Received: from server1.bharatmart.com (ensim.rackshack.net [207.44.196.29]) by bharatmail.com (8.11.6/8.11.6) with ESMTP id h2HFNK716291 for sip@ietf.org; Mon, 17 Mar 2003 09:23:20 -0600 Message-Id: <200303171523.h2HFNK716291@bharatmail.com> Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: binary MIME-Version: 1.0 X-Mailer: MIME-tools 5.411 (Entity 5.404) From: murali To: sip@ietf.org Date: Mon Mar 17 18:28:07 2003 Content-Transfer-Encoding: binary Subject: [Sip] sip grammar Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: binary Hi, When i was going through the SIP Document: draft-ietf-sip-call-flows-05.txt i came across a From Header which is like this INVITE sip:+1-650-555-2222@ss1.wcom.com;user=phone SIP/2.0 Via: SIP/2.0/UDP ift.here.com:5060 From: sip:+1-303-555-1111@ift.here.com;user=phone To: Call-ID: 1717@ift.here.com CSeq: 17 INVITE Contact: Content-Type: application/sdp Content-Length: 146 v=0 o=IFAXTERMINAL01 2890844527 2890844527 IN IP4 ift.here.com s=Session SDP c=IN IP4 iftmg.here.com t=0 0 m=audio 3456 RTP/AVP 0 a=rtpmap:0 PCMU/8000 (Ref: 3.1.7 Successful SIP to SIP with re-INVITE) but Section 20.20 of RFC 3261 says that "Even if the "display-name" is empty, the "name-addr" form MUST be used if the "addr-spec" contains a comma, question mark, or semicolon" so, i'd like to know if the above usage is correct? In case it is correct how do i differentiate between the from parameters and URI-parameters as both are delimited by ;. I mean to say that i can very well take that(user=phone) as generic parameter in from parameters instead of taking it as uri parameter Thanks in advance Murali ------- Murali Voleti, #503,Maheswari complex, Masab Tank, Hyderabad Tele:(040) 6502272 ext:211 _____________________________________________________________ Get Your Free ScanMail and Email At http://mail.ttkbharatplanet.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Mon Mar 17 16:47:03 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03357 for ; Mon, 17 Mar 2003 16:47:03 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2HM3a606294 for sip-archive@odin.ietf.org; Mon, 17 Mar 2003 17:03:36 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2HM37O06287; Mon, 17 Mar 2003 17:03:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2HHoKO18915 for ; Mon, 17 Mar 2003 12:50:20 -0500 Received: from iisc.ernet.in (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21751 for ; Mon, 17 Mar 2003 12:33:18 -0500 (EST) Received: from eis.iisc.ernet.in (eis.iisc.ernet.in [144.16.64.5]) by iisc.ernet.in (8.9.2/8.9.0) with SMTP id XAA43780 for ; Mon, 17 Mar 2003 23:08:50 +0530 (IST) Received: by eis.iisc.ernet.in (SMI-8.6/SMI-4.1) id XAA23141; Mon, 17 Mar 2003 23:05:25 +0530 From: anand@eis.iisc.ernet.in (SVR Anand) Message-Id: <200303171735.XAA23141@eis.iisc.ernet.in> To: sip@ietf.org Date: Mon, 17 Mar 2003 23:05:25 +0530 (GMT+05:30) X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] SIP proxy network Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, Not sure if I am sending my mail to the proper mailing list. Just a wild thought. Can I think of network of SIP proxies connected in some way dynamically exchanging messages in order to assist in forwarding of say, INVITES to an appropriate proxy ? Just like OSPF for link state information, proxy network for say proxy configuration information exchange ? Please let me know if I am talking sense. Anand _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Tue Mar 18 07:31:50 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09438 for ; Tue, 18 Mar 2003 07:31:50 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2ICmgO11092 for sip-archive@odin.ietf.org; Tue, 18 Mar 2003 07:48:42 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2ICd1O10820; Tue, 18 Mar 2003 07:39:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2ICWHO09896 for ; Tue, 18 Mar 2003 07:32:17 -0500 Received: from sonim-india.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08731 for ; Tue, 18 Mar 2003 07:14:51 -0500 (EST) Received: (from root@localhost) by sonim-india.com (8.11.6/8.11.6) id h2IBgXJ00970 for ; Tue, 18 Mar 2003 17:12:33 +0530 Received: from boxer (boxer.sonim-india.com [192.168.2.88]) by sonim-india.com (8.11.6/8.11.6) with SMTP id h2IBgVl00885 for ; Tue, 18 Mar 2003 17:12:32 +0530 From: "Vishal Verma" To: Date: Tue, 18 Mar 2003 17:51:15 +0530 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 X-AntiVirus: Scanned for Viruses at sonim communications (india) pvt. ltd. Content-Transfer-Encoding: 7bit Subject: [Sip] query regarding SDP exchange Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hello friends , I have query regarding SDP exchange during SIP call establishment let us say user A calls user B .User A supports audio codec 1 while user B supports audio codec 2. In this situation SDPs will not match. My questions are 1. What is the response code to indicate this failure to originator ? 2. Are there any mandatory audio codecs that must be supported by SIP devices? regards, vishal _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Tue Mar 18 09:48:46 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11749 for ; Tue, 18 Mar 2003 09:48:46 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2IF5fS18732 for sip-archive@odin.ietf.org; Tue, 18 Mar 2003 10:05:41 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IF4VO18622; Tue, 18 Mar 2003 10:04:31 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IEwPO18362 for ; Tue, 18 Mar 2003 09:58:25 -0500 Received: from rtp-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11636 for ; Tue, 18 Mar 2003 09:40:58 -0500 (EST) Received: from dingdong.cisco.com (IDENT:mirapoint@dingdong.cisco.com [64.102.17.16]) by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h2IEh5vD026604; Tue, 18 Mar 2003 09:43:06 -0500 (EST) Received: from cisco.com (klingle-ultra.cisco.com [64.102.93.47]) by dingdong.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ABW13237; Tue, 18 Mar 2003 09:43:04 -0500 (EST) Message-ID: <3E773078.6B33D842@cisco.com> Date: Tue, 18 Mar 2003 09:43:04 -0500 From: Kevin Lingle X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: sip@ietf.org Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-mib-05.txt References: <200303071154.GAA21633@ietf.org> <3E723571.5060300@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit jonathan, thanks for your comments. please send more if you have them. my comments inline below... Jonathan Rosenberg wrote: > > I have begun to look at the mib a bit, and I am a bit concerned that > there is far too much information exposed, in terms of statistics, at > least. I have to apologize for raising this so late in the game, but it > is only recently that my day job has brought me into OAMP areas. not sure if the above reference to statistics is directly related to your comment on sipTransactionTable below or not. if not, are there other statistics that you feel fall into the category or exposing far too much information? > > One item that struck me as particularly demanding on an implementation > is the sipTransactionTable. There is a huge amount of work in > maintaining this table. I really doubt people will want to implement it. i had similar feedback from others when support of the sipTransactionTable was being considered by a project. the effort involved in supporting the table was a problem. we can focus some discussion on the viability of the table during wg last call. i'd rather do that than to yank the table w/out further discussion. at the very least, we can definitely make the table optional. right now it appears to be in a mandatory group - which seem wrong to me anyway. kevin > My suspicion is that this kind of information will normally be logged by > implementations, and when you need it, its not in real time, but rather > through some kind of offline analysis of the logs. > > Generally, it is my perception that MIB status variables are primarily > aimed at fault and performance analysis. I dont see how a full list of > each transaction, with the call-id, cseq and all, supports either aim. > > Thanks, > Jonathan R. > > Internet-Drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > This draft is a work item of the Session Initiation Protocol Working Group of the IETF. > > > > Title : Management Information Base for Session Initiation > > Protocol > > Author(s) : K. Lingle, J. Maeng, J. Mule, D. Walker > > Filename : draft-ietf-sip-mib-05.txt > > Pages : 97 > > Date : 2003-3-6 > > > > This memo defines a portion of the Management Information Base (MIB) > > for use with network management protocols in the Internet community. > > In particular, it describes a set of managed objects that are used > > to manage Session Initiation Protocol (SIP) entities, which include > > User Agents, Proxy servers, Redirect servers and Registrars. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-sip-mib-05.txt > > > > To remove yourself from the IETF Announcement list, send a message to > > ietf-announce-request with the word unsubscribe in the body of the message. > > > > Internet-Drafts are also available by anonymous FTP. Login with the username > > "anonymous" and a password of your e-mail address. After logging in, > > type "cd internet-drafts" and then > > "get draft-ietf-sip-mib-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-mib-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. > > > > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Kevin R. Lingle 919.392.2029 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Tue Mar 18 19:58:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09810 for ; Tue, 18 Mar 2003 19:58:10 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2J1FHe04463 for sip-archive@odin.ietf.org; Tue, 18 Mar 2003 20:15:17 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2J1EbO04416; Tue, 18 Mar 2003 20:14:37 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2J1AvO04264 for ; Tue, 18 Mar 2003 20:10:57 -0500 Received: from dewberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09470 for ; Tue, 18 Mar 2003 19:53:19 -0500 (EST) Received: from cs.columbia.edu (ca-71-247.wired.ietf56.ietf.org [130.129.71.247]) (user=hgs10 mech=PLAIN bits=0) by dewberry.cc.columbia.edu (8.12.8/8.12.8) with ESMTP id h2J0tS0S001145 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 18 Mar 2003 19:55:29 -0500 (EST) Message-ID: <3E77BF4B.10203@cs.columbia.edu> Date: Tue, 18 Mar 2003 19:52:27 -0500 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030210 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bob Penfield CC: sip@ietf.org, jmpolk@cisco.com References: <000401c2eca0$e60f2570$ec458182@BPenfield> In-Reply-To: <000401c2eca0$e60f2570$ec458182@BPenfield> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Re: use of 420 in draft-polk-sip-resource-02.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > In section 4.2, it says the 420 (Extension Required) response is used if the > SIP element does not understand the "Resource-Priority" tag or it does not > understand the namespace or priority value. And if the Require mechanism is in use. (This is not always the case; indeed, it is not usually desired.) > > I believe this is in conflict with the use of the 417 response described in > section 4.1 and the proper use of 420 as described in RFC 3261. Why? 417 is used if the request fails due to lack of Rewsource-Priority. This is subtly different - it indicates that the priority may not be high enough, say. > > The 420 response should only be used if it does not understand the feature > tag. The 417 response (as described in section 4.1) should be used when it > does not understand the namespace or priority value. If 420 was only used as > described in 3261, the Accept-Resource-Priority header would not appear in a > 420 response. Why couldn't an Accept-Resource-Priority header appear in a 420? There is no restriction on what header fields can appear in a response. I agree that there may be a need to refactor the error cases, as the current description is less than clear. There seem to be the following cases: (0) UAS does *not* know R-P and no Require --> normal SIP behavior, as if there was no R-P indication at all (likely, 503) (1) UAS does *not* know R-P and it is Required --> clearly, 420 (2) UAS does know R-P: (2s) User insists on 'strict' handling (via Require) (2s1) UAS does not support namespace or priority --> 417, with Allow-R-P (2s2) lack of resources --> 417 (2s3) not authorized for this level --> 403 (2L) User allows 'loose' handling (no Require) (2L1) UAS does not support namespace or priority --> tries to queue as if no R-P, might fail as 2L2 (2L2) lack of resources and no queueing for non-priority calls --> 417 or maybe 503 (2L3) not authorized for this level --> ignores R-P, might fall back to 2L2 case Does that cover the cases? > > cheers, > (-:bob > > Robert F. Penfield > Chief Software Architect > Acme Packet, Inc. > 130 New Boston Street > Woburn, MA 01801 > bpenfield@acmepacket.com > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Tue Mar 18 21:26:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12393 for ; Tue, 18 Mar 2003 21:26:29 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2J2hc110461 for sip-archive@odin.ietf.org; Tue, 18 Mar 2003 21:43:38 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2J2h0O10436; Tue, 18 Mar 2003 21:43:00 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2J2dsO10353 for ; Tue, 18 Mar 2003 21:39:54 -0500 Received: from sunserver1.ietf56.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12303 for ; Tue, 18 Mar 2003 21:22:13 -0500 (EST) Received: from sunray129.wired.ietf56.ietf.org ([130.129.64.129] helo=BPenfield) by sunserver1.ietf56.ietf.org with smtp (Exim 4.12) id 18vTFh-00010p-00; Tue, 18 Mar 2003 21:24:25 -0500 Message-ID: <000901c2edbe$a79a9490$81408182@BPenfield> From: "Bob Penfield" To: "Henning Schulzrinne" Cc: , References: <000401c2eca0$e60f2570$ec458182@BPenfield> <3E77BF4B.10203@cs.columbia.edu> Subject: Re: [Sip] Re: use of 420 in draft-polk-sip-resource-02.txt Date: Tue, 18 Mar 2003 21:24:22 -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.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit You seem to be supporting my point of view. But just to clarify, I think the text in section 4.2 which now reads: Following standard behavior (Section 8.2.2.3 of [2]), a UAS MUST then reject the request with response code 420 (Bad Extension) if it does not understand the mechanism, the namespace or the priority value. If the UAS is capable of the resource priority indication in general, but does not understand the namespace or priority value, it MUST also include a Accept-Resource-Priority header field indicating the namespace- priority combinations it can accept. Should be changed to: Following standard behavior (Section 8.2.2.3 of [2]), a UAS MUST then reject the request with response code 420 (Bad Extension) if it does not understand the mechanism. If the UAS is capable of the resource priority indication in general, but does not understand the namespace or priority value, it MUST reject the request with response code 417 and also include a Accept-Resource-Priority header field indicating the namespace-priority combinations it can accept. It should not use 420 if the UAS *does* understand the mechanism. cheers, (-:bob Robert F. Penfield Chief Software Architect Acme Packet, Inc. 130 New Boston Street Woburn, MA 01801 bpenfield@acmepacket.com ----- Original Message ----- From: "Henning Schulzrinne" To: "Bob Penfield" Cc: ; Sent: Tuesday, March 18, 2003 7:52 PM Subject: [Sip] Re: use of 420 in draft-polk-sip-resource-02.txt > > In section 4.2, it says the 420 (Extension Required) response is used if the > > SIP element does not understand the "Resource-Priority" tag or it does not > > understand the namespace or priority value. > > And if the Require mechanism is in use. (This is not always the case; > indeed, it is not usually desired.) > > > > > I believe this is in conflict with the use of the 417 response described in > > section 4.1 and the proper use of 420 as described in RFC 3261. > > Why? 417 is used if the request fails due to lack of Rewsource-Priority. > This is subtly different - it indicates that the priority may not be > high enough, say. > > > > > The 420 response should only be used if it does not understand the feature > > tag. The 417 response (as described in section 4.1) should be used when it > > does not understand the namespace or priority value. If 420 was only used as > > described in 3261, the Accept-Resource-Priority header would not appear in a > > 420 response. > > Why couldn't an Accept-Resource-Priority header appear in a 420? There > is no restriction on what header fields can appear in a response. > > I agree that there may be a need to refactor the error cases, as the > current description is less than clear. There seem to be the following > cases: > > (0) UAS does *not* know R-P and no Require --> normal SIP behavior, as > if there was no R-P indication at all (likely, 503) > > (1) UAS does *not* know R-P and it is Required --> clearly, 420 > > (2) UAS does know R-P: > > (2s) User insists on 'strict' handling (via Require) > > (2s1) UAS does not support namespace or priority --> 417, with Allow-R-P > > (2s2) lack of resources --> 417 > > (2s3) not authorized for this level --> 403 > > (2L) User allows 'loose' handling (no Require) > > (2L1) UAS does not support namespace or priority --> tries to queue as > if no R-P, might fail as 2L2 > > (2L2) lack of resources and no queueing for non-priority calls --> 417 > or maybe 503 > > (2L3) not authorized for this level --> ignores R-P, might fall back to > 2L2 case > > Does that cover the cases? > > > > > 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 > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Wed Mar 19 08:22:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20441 for ; Wed, 19 Mar 2003 08:22:39 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2JDe1F28864 for sip-archive@odin.ietf.org; Wed, 19 Mar 2003 08:40:01 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2JDdXO28810; Wed, 19 Mar 2003 08:39:33 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2JDYEO27851 for ; Wed, 19 Mar 2003 08:34:14 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20345 for ; Wed, 19 Mar 2003 08:16:21 -0500 (EST) Received: from dynamicsoft.com (dyn-tx-app-004.dfw.dynamicsoft.com [63.110.3.2]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h2J5IxBd000823; Wed, 19 Mar 2003 00:20:14 -0500 (EST) Message-ID: <3E77FDBB.6050304@dynamicsoft.com> Date: Wed, 19 Mar 2003 00:18:51 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Shane McCormack CC: "Sip@Ietf. Org" Subject: Re: [Sip] SUBSCRIBE for Geographical Coordinates References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Right now, there is no way to do it, principally because there is no standard way to represent geographic information. However, the geopriv working group is working on a means for describing geographic location information. There was a draft recently on using presence (e.g., draft-ietf-simple-presence) to subscribe to such information: http://www.ietf.org/internet-drafts/draft-peterson-geopriv-pres-00.txt -Jonathan R. Shane McCormack wrote: > Hi, > > Im just wondering how to return geographical coordinates for a sip user > agent. The Scenario would be SIP Location enabled handsets(GPS?). > Would you use an event notification package and if so would the requirements > be simiilar to subscribing to presence events only returning a geographical > coordinate on a specific time interval. Any feedback would be helpful. > > Regards > ShaneShane McCormack > > Research Assistant, > TSSG, Confederation House, > Waterford Business Park, Cork Road, > Waterford, Co. Waterford. > > Phone: +353 51 302927 Fax: +353 51 302901 > Mobile: +353 87 9955505 > http://www.tssg.org > MSN: mccormackshane@hotmail.com > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Wed Mar 19 08:24:53 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20483 for ; Wed, 19 Mar 2003 08:24:53 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2JDgEn28985 for sip-archive@odin.ietf.org; Wed, 19 Mar 2003 08:42:14 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2JDfpO28958; Wed, 19 Mar 2003 08:41:51 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2JDYHO27861 for ; Wed, 19 Mar 2003 08:34:17 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20347 for ; Wed, 19 Mar 2003 08:16:22 -0500 (EST) Received: from dynamicsoft.com (dyn-tx-app-004.dfw.dynamicsoft.com [63.110.3.2]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h2J53UBd000813; Wed, 19 Mar 2003 00:04:27 -0500 (EST) Message-ID: <3E77FA1B.10600@dynamicsoft.com> Date: Wed, 19 Mar 2003 00:03:23 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kevin Lingle CC: sip@ietf.org Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-mib-05.txt References: <200303071154.GAA21633@ietf.org> <3E723571.5060300@dynamicsoft.com> <3E773078.6B33D842@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Kevin Lingle wrote: >>I have begun to look at the mib a bit, and I am a bit concerned that >>there is far too much information exposed, in terms of statistics, at >>least. I have to apologize for raising this so late in the game, but it >>is only recently that my day job has brought me into OAMP areas. > > > not sure if the above reference to statistics is directly related > to your comment on sipTransactionTable below or not. Yes. > if not, are there > other statistics that you feel fall into the category or > exposing far too much information? I want to look some more and provide some additional comments. > > >>One item that struck me as particularly demanding on an implementation >>is the sipTransactionTable. There is a huge amount of work in >>maintaining this table. I really doubt people will want to implement it. > > > i had similar feedback from others when support of the sipTransactionTable > was being considered by a project. the effort involved in supporting > the table was a problem. > > we can focus some discussion on the viability of the table during wg last call. Well, discussion can happen any time. Its happening now, in this email thread. I dont know what else you are expecting. I don't think the table is viable. You had similar feedback. Seems like a clear cut resolution to me. > i'd rather do that than to yank the table w/out further discussion. *This* is the discussion. > at the very least, we can definitely make the table optional. > right now it appears to be in a mandatory group - which seem wrong to me anyway. Mandatory is definitely wrong. I am not even sure optional is useful. So - here is the question. What is the bar for putting something in the MIB? At one extreme, every piece of state managed by a server could be in the mib. At the other extreme, there is nothing, or a single summary statistic. I think a reasonable bar, is that there should be clear value in monitoring that information, from the perspective of fault and performance management in particular. If you cannot demonstrate such a use, it should be out. I cannot think of a reason that I would want, from an operations center, to monitor the current set of transactions held in the system. Thus, I think it should be out. Is not our aim to take things out of protocols until we can't take out any more, rather than the other way around? -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Wed Mar 19 09:22:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21295 for ; Wed, 19 Mar 2003 09:22:39 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2JEe3T00512 for sip-archive@odin.ietf.org; Wed, 19 Mar 2003 09:40:03 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2JEWeO31937; Wed, 19 Mar 2003 09:32:40 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2JETRO31800 for ; Wed, 19 Mar 2003 09:29:27 -0500 Received: from hotmail.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21170 for ; Wed, 19 Mar 2003 09:11:32 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 19 Mar 2003 06:13:47 -0800 Received: from 212.143.185.30 by by2fd.bay2.hotmail.msn.com with HTTP; Wed, 19 Mar 2003 14:13:46 GMT X-Originating-IP: [212.143.185.30] X-Originating-Email: [eronstein@hotmail.com] From: "Eron Stein" To: sip@ietf.org Date: Wed, 19 Mar 2003 09:13:46 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 19 Mar 2003 14:13:47.0085 (UTC) FILETIME=[C1B2D7D0:01C2EE21] Subject: [Sip] TLS post connection verification Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Hi, When sending a request (ie REGISTER) to a server I can compare the request URI to the common name (or the alt dns name) in the certificate. If the names match, I can conclude that the certificate is OK. (I'm using OpenSSL, and they recommend this post connection assertion). I have two questions thou: 1 - What name should I use for comparison when accepting a connection? Usually only the UAC will demand certificate, I am concerned with te case of two proxies trying to connect using TLS and the UAS proxy asking for client certificates. (what uri will the UAS proxy has, there is no message yet). 2 - how should broken connection be handled? lets say UAC1 sent a request over TLS to UAS1. the handshake went well and the request sent. than for some reason, the connection was broken and UAS1 now needs to reestablish the connection. What should UAS1 do? use TLS w/out certificates? Regards, Eron Stein _________________________________________________________________ The new MSN 8: advanced junk mail protection and 2 months FREE* http://join.msn.com/?page=features/junkmail _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Wed Mar 19 10:49:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24149 for ; Wed, 19 Mar 2003 10:49:57 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2JG7M006248 for sip-archive@odin.ietf.org; Wed, 19 Mar 2003 11:07:22 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2JG0OO05362; Wed, 19 Mar 2003 11:00:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2JFuGO05177 for ; Wed, 19 Mar 2003 10:56:16 -0500 Received: from rtp-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23745 for ; Wed, 19 Mar 2003 10:38:19 -0500 (EST) Received: from dingdong.cisco.com (IDENT:mirapoint@dingdong.cisco.com [64.102.17.16]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2JFeHSc028300; Wed, 19 Mar 2003 10:40:18 -0500 (EST) Received: from cisco.com (klingle-ultra.cisco.com [64.102.93.47]) by dingdong.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ABW47232; Wed, 19 Mar 2003 10:40:17 -0500 (EST) Message-ID: <3E788F61.D7610086@cisco.com> Date: Wed, 19 Mar 2003 10:40:17 -0500 From: Kevin Lingle X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: sip@ietf.org, Dave Walker Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-mib-05.txt References: <200303071154.GAA21633@ietf.org> <3E723571.5060300@dynamicsoft.com> <3E773078.6B33D842@cisco.com> <3E77FA1B.10600@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > > Kevin Lingle wrote: > > >>I have begun to look at the mib a bit, and I am a bit concerned that > >>there is far too much information exposed, in terms of statistics, at > >>least. I have to apologize for raising this so late in the game, but it > >>is only recently that my day job has brought me into OAMP areas. > > > > > > not sure if the above reference to statistics is directly related > > to your comment on sipTransactionTable below or not. > > Yes. > > > if not, are there > > other statistics that you feel fall into the category or > > exposing far too much information? > > I want to look some more and provide some additional comments. that would be great. > > > > > > >>One item that struck me as particularly demanding on an implementation > >>is the sipTransactionTable. There is a huge amount of work in > >>maintaining this table. I really doubt people will want to implement it. > > > > > > i had similar feedback from others when support of the sipTransactionTable > > was being considered by a project. the effort involved in supporting > > the table was a problem. > > > > we can focus some discussion on the viability of the table during wg last call. > > Well, discussion can happen any time. Its happening now, in this email > thread. I dont know what else you are expecting. sorry. didn't mean to imply what came across. we can definitely discuss it now. i'm just not used to actually having active discussion of the mib. i'm used to getting one or two sporatic comments and only having focused discussion during last call - when someone is forced to review the mib ;) > I don't think the table > is viable. You had similar feedback. Seems like a clear cut resolution > to me. not that i don't take your point of view as very significant, i do. i was hoping that others might concur before we decide to remove the table. the table has been in every revision of the mib, so it has been reviewed multiple times by multiple people... no one - until now has recommended it come out. i guess i had taken that as acceptance of it's potential usefulness to someone. my case of one project finding it questionable does not necessarily make a case for it's removal. we determined that support was feasible but not all that useful for our platform. implementation experience with a mib usually decides such things and we don't have much (any?) feedback in that area (not likely to until the mibs are in an rfc). still, if we can resolve the question of usefulness now it would be better than to have to revise the mib (ie, rfc) and deprecate objects found - through implementation experience - to be useless. > > > i'd rather do that than to yank the table w/out further discussion. > > *This* is the discussion. agreed. > > > at the very least, we can definitely make the table optional. > > right now it appears to be in a mandatory group - which seem wrong to me anyway. > > Mandatory is definitely wrong. I am not even sure optional is useful. > > So - here is the question. What is the bar for putting something in the > MIB? At one extreme, every piece of state managed by a server could be > in the mib. At the other extreme, there is nothing, or a single summary > statistic. I think a reasonable bar, is that there should be clear value > in monitoring that information, from the perspective of fault and > performance management in particular. If you cannot demonstrate such a > use, it should be out. > > I cannot think of a reason that I would want, from an operations center, > to monitor the current set of transactions held in the system. Thus, I > think it should be out. it's hard for me to justify or defend the existence of this table as i was not the original author of it. but for the sake of discussion... is there no value from a troubleshooting perspective? you mentioned that this information is likely logged for offline analysis - not real-time. are transactions generally occuring too fast for real-time analysis to be of worth? it would seem to me that unless you know specifically which transactions are of interest to you, it would be hard to use this table for anything. the table is defintely not a logging mechanism as transactions will not persist for any historically significant time. from a performance mgmt point of view... could the increase in entries in this table be used to gain insight into congestion in this or other parts of the sip network? even if that were the case, the simple sipCurrentTransactions gauge object would provide similar insight (to congestion at least). perhaps the to/from details in the table would lend some more insight to problems elsewhere in the network? i'm not sure. dave walker was the original author of this table, so maybe he can offer some insight. dave? i did find one old comment related to this table squirreled away in some old emails.... Kurt Robohm wrote: > > sipCurrentTransacations Does this reflect number of > calls in progress? > Intent of objects in table to > sipTransactionTable provide real time info on > number of calls being handled > real time? Dave Walker responded: > Transactions aren't calls. The intent, as mentioned in Adelaide, > is to evolve the transaction table to a call leg table (probably > for UAs only). This hasn't been resolved yet, so no real changes > were made. i can't find any further discussion by dave (or others) in subsequent revisions of the draft to work out any further evolution of this table. only minor comments related to the table - none questioning its existence. dave's involvement in the last couple of revisions of the draft have been nil. so perhaps the table is an articfact of an idea that was not fully conceived or fleshed out. that would lend itself to removal imo. kevin > > Is not our aim to take things out of protocols until we can't take out > any more, rather than the other way around? > > -Jonathan R. > > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Kevin R. Lingle 919.392.2029 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Wed Mar 19 11:22:34 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24986 for ; Wed, 19 Mar 2003 11:22:34 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2JGe1L08650 for sip-archive@odin.ietf.org; Wed, 19 Mar 2003 11:40:01 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2JGVjO07424; Wed, 19 Mar 2003 11:31:45 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2JGSFO07251 for ; Wed, 19 Mar 2003 11:28:15 -0500 Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24697 for ; Wed, 19 Mar 2003 11:10:07 -0500 (EST) Received: from dynamicsoft.com (dyn-tx-app-004.dfw.dynamicsoft.com [63.110.3.2]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h2J58EBd000816; Wed, 19 Mar 2003 00:09:29 -0500 (EST) Message-ID: <3E77FB36.2040804@dynamicsoft.com> Date: Wed, 19 Mar 2003 00:08:06 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Vijay K. Gurbani" CC: Dean Willis , "'F.S.Salloum'" , "'Sip@Ietf. Org'" , "'Tasos Dagiouklas'" Subject: Re: [Sip] Of-hook and On-hook @ sip? References: <007201c2dddd$3c1dc4d0$ee036e3f@txdwillis> <3E5D36ED.5050800@lucent.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Well, we have the dialog event package which allows you to find out the state of dialogs at a UA: http://www.ietf.org/internet-drafts/draft-ietf-sipping-dialog-package-01.txt -Jonathan R. Vijay K. Gurbani wrote: > Dean Willis wrote: > [...] > >> Option 3: We use an event package, and the upstream server subscribes >> to the >> session state of my adapter. When my adapter starts a session, it sends a >> NOTIFY to the server saying "I have a session, for which I have an >> identifier.". When my adapter stops a session, it sends anotehr NOIFY >> saying >> "This session (using identifier) has ended". > > > One such event package is specified by the SPIRITS protocol. For > implementation experience, see: > http://www.ietf.org/internet-drafts/draft-gurbani-spirits-implementation-00.txt > > > Cheers, > > - vijay -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Wed Mar 19 14:30:18 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02361 for ; Wed, 19 Mar 2003 14:30:17 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2JJllf26667 for sip-archive@odin.ietf.org; Wed, 19 Mar 2003 14:47:47 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2JJkxO26607; Wed, 19 Mar 2003 14:46:59 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2JJejO25981 for ; Wed, 19 Mar 2003 14:40:45 -0500 Received: from sunserver1.ietf56.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01938 for ; Wed, 19 Mar 2003 14:22:45 -0500 (EST) Received: from wl-136-149.wireless.ietf56.ietf.org ([130.129.136.149] helo=localhost.localdomain) by sunserver1.ietf56.ietf.org with esmtp (Exim 4.12) id 18vjBJ-0002LL-00; Wed, 19 Mar 2003 14:24:57 -0500 Received: from localhost.localdomain (localhost [127.0.0.1]) by localhost.localdomain (8.12.8/8.12.5) with ESMTP id h2JJOV93019637; Wed, 19 Mar 2003 21:24:31 +0200 Received: (from ppessi@localhost) by localhost.localdomain (8.12.8/8.12.5/Submit) id h2JJLWQv019444; Wed, 19 Mar 2003 21:21:32 +0200 X-Authentication-Warning: localhost.localdomain: ppessi set sender to Pekka.Pessi@nokia.com using -f To: sip@ietf.org Cc: rsparks@dynamicsoft.com, jon.peterson@neustar.biz X-face: #V(jdpv[lI!TNUU=2*oh:="#suS*ponXW"yr6G;~L}uZ\JfD\"IG#G{j`hZI;=DmT\H pfDMyJ`i=:M;BM3R.`[>P^ER8+]i From: Pekka Pessi Date: Wed, 19 Mar 2003 21:21:32 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Sip] Referred-By Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Hello all, I *think* I volunteered to review referredby, so here I go. My first interpretation was that the AIB body should contain copies of the (header) fields from REFER request. However, there is language in a note within section 4 that suggested otherwise. The suggestion here is that the Referred-By token would be an AIB usable by referree. I think most of the open issues and confusing stuff in the spec is because of this. The draft tries to define how a referrer could construct a AIB that a referree could send and target could check almost like a AIB, but not quite. Obviously, this is pretty hard task. Does Referred-By token (RBT) warrant a disposition-type of its own? I feel that it does - otherwise it is bit hard to authenticate origin of REFER request with AIB. Also, referree may include its own AIB in the referred request. Validating ordinary AIB or RBT are different tasks, so I think it will only create confusion if they both use same disposition-type. Sooo. Here is my proposal: - define a disposition-type for RBT ("referred-by+aib") - determine which headers put in the token Referred-By, Refer-To, Date, [Expires], [To] because token is not an ordinary AIB, no Call-ID or CSeq is needed. - determine how target validates token - To in incoming request should match Refer-To in RBT - From in incoming request should match To in RBT - Referred-By URL in incoming request should match Referred-By in RBT But back to open issue #1. How to determine that the real referree is sending the request to target? Include the identity in Referred-By header, so that the target could use it in From header and authenticate itself using an ordinary AIB? Include the From header used by referree in NOTIFY/429 body? BR, Pekka _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Wed Mar 19 16:01:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07820 for ; Wed, 19 Mar 2003 16:01:36 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2JLJ8804460 for sip-archive@odin.ietf.org; Wed, 19 Mar 2003 16:19:08 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2JLIIO04389; Wed, 19 Mar 2003 16:18:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2JLCdO03981 for ; Wed, 19 Mar 2003 16:12:39 -0500 Received: from dyn-tx-arch-crash.dfw.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07473; Wed, 19 Mar 2003 15:54:36 -0500 (EST) Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h2JKuo924748; Wed, 19 Mar 2003 14:56:50 -0600 From: Robert Sparks Reply-To: sip@ietf.org To: sip@ietf.org, simple@ietf.org, sipping@ietf.org Content-Type: text/plain Message-Id: <1048107377.1063.49.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 19 Mar 2003 12:56:18 -0800 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] [Fwd: RE: SIP WG bugzilla instance] Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit All - I apologize now for violating the no-crosspost policy, but this spans all the groups. Please, please, reply _ONLY_ to sip@ietf.org (which is what should happen if you hit your reply button if I've built this message correctly). If you have any opinions, positive or negative, about our use of bugzilla for issue tracking and whether other groups should follow the model, now would be a good time to comment. Thanks! RjS -----Forwarded Message----- > From: john.loughney@nokia.com > To: rsparks@dynamicsoft.com, wgchairs@ietf.org > Subject: RE: SIP WG bugzilla instance > Date: 19 Mar 2003 22:46:52 +0200 > > Robert, > > Any comments on how the WG & WG Chairs like it? > > John > > > At the session on improving working group chair training > > (and chair effectiveness), tools came up. The SIP related > > working groups have been effectively using a bugzilla variant > > to track document issues and help drive open issues to > > conclusion. > > > > It's available at http://www.sipwg.org (or http://bugs.sipit.net). > > > > One point to bring forth at the beginning - we use this as > > a tracking tool, not an alternative venue for list discussion. > > Document/issue owners are able to make changes to a bug - > > people ask the owner to add things to the tracking tool on > > the appropriate list. The chairs make sure that the owners > > accurately capture threads on the tracking tool. > > > > RjS > > > > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Wed Mar 19 17:52:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13290 for ; Wed, 19 Mar 2003 17:52:51 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2JNAPk16579 for sip-archive@odin.ietf.org; Wed, 19 Mar 2003 18:10:25 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2JN6fO15573; Wed, 19 Mar 2003 18:06:41 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2JN3OO15412 for ; Wed, 19 Mar 2003 18:03:24 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13035 for ; Wed, 19 Mar 2003 17:45:18 -0500 (EST) From: hisham.khartabil@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.5/Switch-2.2.5) with ESMTP id h2JMpCu10650 for ; Thu, 20 Mar 2003 00:51:12 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 20 Mar 2003 00:47:37 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 20 Mar 2003 00:47:33 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 20 Mar 2003 00:47:33 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sip] NOTIFY establishes a dialog Date: Thu, 20 Mar 2003 00:47:33 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7FE73E7@esebe019.ntc.nokia.com> Thread-Topic: NOTIFY establishes a dialog Thread-Index: AcLorUZXIKW9Ox8mR6CJcIp4fE/dfAFuETAA To: X-OriginalArrivalTime: 19 Mar 2003 22:47:33.0732 (UTC) FILETIME=[87CFE240:01C2EE69] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2JN3OO15413 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit I have a few related questions/comments: - A 180 response to a request (like INVITE) establishes a dialog. This 180 response carries record-route headers and therefore sets the route-set. The 200 response to the request might also carry record-route headers. The dialog transitions to confirmed state, but I assume the route-set does not get updated using the record-route headers in the 200 response since the dialog is established already. Is this a correct assumption? should the UAS send record-route headers at all in the 200 if it sent a 1xx already? Should there be a mandate that 1xx and 2xx response carry the same record-route headers? You would assume that this happens naturally at the UAS, but proxies may play around with the record-route headers. - In the NOTIFY problem below, the NOTIFY establishes the dialog, but does not carry record-route headers. If the same assumption is made as above, the record-route headers appearing in the 200 response to the SUBSCRIBE are ignored since the dialog is in established state. Isn't this a problem? the route-set is lost. I appreciate some clarifications. Regards, Hisham > -----Original Message----- > From: ext hisham.khartabil@nokia.com > [mailto:hisham.khartabil@nokia.com] > Sent: Wednesday, March 12, 2003 5:37 PM > To: sip@ietf.org > Subject: [Sip] NOTIFY establishes a dialog > > > In RFC3265, it is mentioned that NOTIFY can certainly > establish a dialog if it arrives before the 200 of a > SUBSCRIBE. What happens when the 200 for the SUBSCRIBE now > arrives with record-route headers? Does the route-set get > updated? (keeping in mind that the dialog is now in the > established state). > > Regards, > Hisham > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Wed Mar 19 19:53:22 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18517 for ; Wed, 19 Mar 2003 19:53:22 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2K1AvC26040 for sip-archive@odin.ietf.org; Wed, 19 Mar 2003 20:10:57 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2K1AXO26028; Wed, 19 Mar 2003 20:10:33 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2K17UO25722 for ; Wed, 19 Mar 2003 20:07:30 -0500 Received: from ihemail1.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18376 for ; Wed, 19 Mar 2003 19:49:23 -0500 (EST) Received: from ih2mail.ih.lucent.com (h135-1-241-39.lucent.com [135.1.241.39]) by ihemail1.firewall.lucent.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2K0pbQ02358 for ; Wed, 19 Mar 2003 19:51:37 -0500 (EST) Received: from lucent.com by ih2mail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id SAA04880; Wed, 19 Mar 2003 18:51:34 -0600 (CST) Message-ID: <3E791090.1060902@lucent.com> Date: Wed, 19 Mar 2003 18:51:28 -0600 From: "Vijay K. Gurbani" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en MIME-Version: 1.0 To: sip@ietf.org References: <1048107377.1063.49.camel@RjS.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Re: [Simple] [Fwd: RE: SIP WG bugzilla instance] Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Robert Sparks wrote: > All - > > I apologize now for violating the no-crosspost policy, but > this spans all the groups. Please, please, reply _ONLY_ to > sip@ietf.org (which is what should happen if you hit your > reply button if I've built this message correctly). > > If you have any opinions, positive or negative, about our > use of bugzilla for issue tracking and whether other groups > should follow the model, now would be a good time to comment. I think it has helped us immensely in the SIP and SIPPING WGs. It is nice to be able to go to the bug site and view a list of open bugs, and furthermore, track them to completion. - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Wireless Networks Group/Internet Software and Services Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Wed Mar 19 20:01:44 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18817 for ; Wed, 19 Mar 2003 20:01:44 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2K1JKb26545 for sip-archive@odin.ietf.org; Wed, 19 Mar 2003 20:19:20 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2K1InO26514; Wed, 19 Mar 2003 20:18:49 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2K1FBO26333 for ; Wed, 19 Mar 2003 20:15:11 -0500 Received: from dewberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18672 for ; Wed, 19 Mar 2003 19:57:04 -0500 (EST) Received: from cs.columbia.edu (wl-138-255.wireless.ietf56.ietf.org [130.129.138.255]) (user=hgs10 mech=PLAIN bits=0) by dewberry.cc.columbia.edu (8.12.8/8.12.8) with ESMTP id h2K0xHET006835 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 19 Mar 2003 19:59:18 -0500 (EST) Message-ID: <3E7911B1.7090604@cs.columbia.edu> Date: Wed, 19 Mar 2003 19:56:17 -0500 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030210 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Vijay K. Gurbani" CC: sip@ietf.org Subject: Re: [Sip] Re: [Simple] [Fwd: RE: SIP WG bugzilla instance] References: <1048107377.1063.49.camel@RjS.localdomain> <3E791090.1060902@lucent.com> In-Reply-To: <3E791090.1060902@lucent.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit It would be even more helpful if this existed for all active working group documents, automatically, not just the 326* documents. We could then make sure all open issues are automatically included in the next IETF discussion slot. Vijay K. Gurbani wrote: > Robert Sparks wrote: > >> All - >> >> I apologize now for violating the no-crosspost policy, but >> this spans all the groups. Please, please, reply _ONLY_ to >> sip@ietf.org (which is what should happen if you hit your >> reply button if I've built this message correctly). >> >> If you have any opinions, positive or negative, about our >> use of bugzilla for issue tracking and whether other groups >> should follow the model, now would be a good time to comment. > > > I think it has helped us immensely in the SIP and SIPPING WGs. > It is nice to be able to go to the bug site and view a list > of open bugs, and furthermore, track them to completion. > > - vijay _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Wed Mar 19 20:17:26 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19297 for ; Wed, 19 Mar 2003 20:17:26 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2K1Z3E27235 for sip-archive@odin.ietf.org; Wed, 19 Mar 2003 20:35:03 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2K1YCO27171; Wed, 19 Mar 2003 20:34:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2K1VMO27096 for ; Wed, 19 Mar 2003 20:31:22 -0500 Received: from dyn-tx-arch-crash.dfw.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19187 for ; Wed, 19 Mar 2003 20:13:15 -0500 (EST) Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h2K1FN928551; Wed, 19 Mar 2003 19:15:23 -0600 Subject: Re: [Sip] Re: [Simple] [Fwd: RE: SIP WG bugzilla instance] From: Robert Sparks To: Henning Schulzrinne Cc: sip@ietf.org In-Reply-To: <3E7911B1.7090604@cs.columbia.edu> References: <1048107377.1063.49.camel@RjS.localdomain> <3E791090.1060902@lucent.com> <3E7911B1.7090604@cs.columbia.edu> Content-Type: text/plain Message-Id: <1048122886.928.26.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 19 Mar 2003 17:14:46 -0800 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hmm - I'll look at that - probably can't _completely_ automate it, but I might be able to automate prodding the work that it takes to set a document up. In the meantime, I'll remind any WG document owner that all it takes to get the doc into the database is to send me a peice of mail. RjS On Wed, 2003-03-19 at 16:56, Henning Schulzrinne wrote: > It would be even more helpful if this existed for all active working > group documents, automatically, not just the 326* documents. We could > then make sure all open issues are automatically included in the next > IETF discussion slot. > > Vijay K. Gurbani wrote: > > Robert Sparks wrote: > > > >> All - > >> > >> I apologize now for violating the no-crosspost policy, but > >> this spans all the groups. Please, please, reply _ONLY_ to > >> sip@ietf.org (which is what should happen if you hit your > >> reply button if I've built this message correctly). > >> > >> If you have any opinions, positive or negative, about our > >> use of bugzilla for issue tracking and whether other groups > >> should follow the model, now would be a good time to comment. > > > > > > I think it has helped us immensely in the SIP and SIPPING WGs. > > It is nice to be able to go to the bug site and view a list > > of open bugs, and furthermore, track them to completion. > > > > - vijay > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Wed Mar 19 20:49:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20411 for ; Wed, 19 Mar 2003 20:49:42 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2K27J229823 for sip-archive@odin.ietf.org; Wed, 19 Mar 2003 21:07:19 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2K26tO29406; Wed, 19 Mar 2003 21:06:55 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2K236O29190 for ; Wed, 19 Mar 2003 21:03:06 -0500 Received: from sj-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20231 for ; Wed, 19 Mar 2003 20:44:58 -0500 (EST) Received: from whoami-new.cisco.com (IDENT:mirapoint@whoami-new.cisco.com [64.101.128.102]) by sj-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h2K1l8mU027856; Wed, 19 Mar 2003 17:47:08 -0800 (PST) Received: from ARUNVENKW2Kl (arunvenk-w2kl-2.cisco.com [64.101.164.75]) by whoami-new.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with SMTP id ABB55610; Wed, 19 Mar 2003 19:47:09 -0600 (CST) From: "Arunachalam Venkatraman" To: , Subject: RE: [Sip] NOTIFY establishes a dialog Date: Wed, 19 Mar 2003 19:47:09 -0600 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB7FE73E7@esebe019.ntc.nokia.com> Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hisham The reason the Record_Route headers must be sent on the 200 is that the 1xx is not guaranteed to be delivered, unless they are sent reliably. I think in the context of the Notify crossing the 200, the arrival of the 200 will establish the Route set for future requests. Each transaction completes independently. I am copying in a old message on this subject from the sip list below that you may find useful - (I think it would have been useful to state this in the RFC3261). ------------------ Start Of Old Message -------------------------- > -----Original Message----- > From: Arunachalam Venkatraman [mailto:arunvenk@cisco.com] > Sent: Friday, March 23, 2001 3:39 PM > To: sip-implementors@cs.columbia.edu > Cc: Jonathan Rosenberg > Subject: Replace Contact in Route set ? > > As per the protocol, the Contact header is added to the end of the Route header. > > Suppose a Record-Route was first received in a message with a Contact C1. > The UA has built a route set with the Contact C1 at the bottom of the Route. > > If the next request to the UA has a new Contact C2, should C1 in the Route Set be replaced > with C2? > Yes. And if there was no Contact, don't change anything. Note that if the next request has new record-routes, those do NOT update the existing route sets. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com ---------------------------------End of Old Message ---------------------- -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of hisham.khartabil@nokia.com Sent: Wednesday, March 19, 2003 4:48 PM To: sip@ietf.org Subject: RE: [Sip] NOTIFY establishes a dialog I have a few related questions/comments: - A 180 response to a request (like INVITE) establishes a dialog. This 180 response carries record-route headers and therefore sets the route-set. The 200 response to the request might also carry record-route headers. The dialog transitions to confirmed state, but I assume the route-set does not get updated using the record-route headers in the 200 response since the dialog is established already. Is this a correct assumption? should the UAS send record-route headers at all in the 200 if it sent a 1xx already? Should there be a mandate that 1xx and 2xx response carry the same record-route headers? You would assume that this happens naturally at the UAS, but proxies may play around with the record-route headers. - In the NOTIFY problem below, the NOTIFY establishes the dialog, but does not carry record-route headers. If the same assumption is made as above, the record-route headers appearing in the 200 response to the SUBSCRIBE are ignored since the dialog is in established state. Isn't this a problem? the route-set is lost. I appreciate some clarifications. Regards, Hisham > -----Original Message----- > From: ext hisham.khartabil@nokia.com > [mailto:hisham.khartabil@nokia.com] > Sent: Wednesday, March 12, 2003 5:37 PM > To: sip@ietf.org > Subject: [Sip] NOTIFY establishes a dialog > > > In RFC3265, it is mentioned that NOTIFY can certainly > establish a dialog if it arrives before the 200 of a > SUBSCRIBE. What happens when the 200 for the SUBSCRIBE now > arrives with record-route headers? Does the route-set get > updated? (keeping in mind that the dialog is now in the > established state). > > Regards, > Hisham > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Wed Mar 19 23:15:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23582 for ; Wed, 19 Mar 2003 23:15:25 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2K4X6006441 for sip-archive@odin.ietf.org; Wed, 19 Mar 2003 23:33:06 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2K4IqO05659; Wed, 19 Mar 2003 23:18:52 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2K4F7O05476 for ; Wed, 19 Mar 2003 23:15:07 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22968 for ; Wed, 19 Mar 2003 22:56:55 -0500 (EST) From: hisham.khartabil@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.5/Switch-2.2.5) with ESMTP id h2K42mu12125 for ; Thu, 20 Mar 2003 06:02:48 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 20 Mar 2003 05:59:10 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 20 Mar 2003 05:59:06 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sip] NOTIFY establishes a dialog Date: Thu, 20 Mar 2003 05:59:05 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7FE73EC@esebe019.ntc.nokia.com> Thread-Topic: [Sip] NOTIFY establishes a dialog Thread-Index: AcLugqQWXwLeEBzXQBmEvxKHBRa/EwAEYyig To: , X-OriginalArrivalTime: 20 Mar 2003 03:59:06.0377 (UTC) FILETIME=[0D7F2790:01C2EE95] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2K4F7O05477 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit I don't think you have accurately my questions. The spec says once a dialog is established, you cannot change the route-set. A 180 establishes a dialog, so my assumption is that the 200 ok record-route headers are ignored. The same goes for NOTIFY (by the way, 200 for SUBSCRIBE in going in the same direction as NOTIFY, not crossing on the wire). NOTIFY establishes a dialog and therefore the route-set delivered in the NOTIFY is lost. Your conclusions below break the rule where a route-set cannot be changed once a dialog has been established. /Hisham > -----Original Message----- > From: ext Arunachalam Venkatraman [mailto:arunvenk@cisco.com] > Sent: Thursday, March 20, 2003 3:47 AM > To: Khartabil Hisham (NMP/Helsinki); sip@ietf.org > Subject: RE: [Sip] NOTIFY establishes a dialog > > > Hisham > The reason the Record_Route headers must be sent on the 200 > is that the 1xx > is not guaranteed to be delivered, unless they are sent reliably. > > I think in the context of the Notify crossing the 200, the > arrival of the > 200 will establish the Route set for future requests. Each transaction > completes independently. > > I am copying in a old message on this subject from the sip > list below that > you may find useful - (I think it would have been useful to > state this in > the RFC3261). > > ------------------ Start Of Old Message -------------------------- > > > -----Original Message----- > > From: Arunachalam Venkatraman [mailto:arunvenk@cisco.com] > > Sent: Friday, March 23, 2001 3:39 PM > > To: sip-implementors@cs.columbia.edu > > Cc: Jonathan Rosenberg > > Subject: Replace Contact in Route set ? > > > > As per the protocol, the Contact header is added to the end > of the Route > header. > > > > Suppose a Record-Route was first received in a message with > a Contact C1. > > The UA has built a route set with the Contact C1 at the > bottom of the > Route. > > > > If the next request to the UA has a new Contact C2, should > C1 in the Route > Set be replaced > > with C2? > > > > Yes. And if there was no Contact, don't change anything. > > Note that if the next request has new record-routes, those do > NOT update the > existing route sets. > > -Jonathan R. > --- > Jonathan D. Rosenberg 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > ---------------------------------End of Old Message > ---------------------- > > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of > hisham.khartabil@nokia.com > Sent: Wednesday, March 19, 2003 4:48 PM > To: sip@ietf.org > Subject: RE: [Sip] NOTIFY establishes a dialog > > > I have a few related questions/comments: > > - A 180 response to a request (like INVITE) establishes a > dialog. This 180 > response carries record-route headers and therefore sets the > route-set. The > 200 response to the request might also carry record-route headers. The > dialog transitions to confirmed state, but I assume the > route-set does not > get updated using the record-route headers in the 200 > response since the > dialog is established already. Is this a correct assumption? > should the UAS > send record-route headers at all in the 200 if it sent a 1xx already? > > Should there be a mandate that 1xx and 2xx response carry the same > record-route headers? You would assume that this happens > naturally at the > UAS, but proxies may play around with the record-route headers. > > - In the NOTIFY problem below, the NOTIFY establishes the > dialog, but does > not carry record-route headers. If the same assumption is > made as above, the > record-route headers appearing in the 200 response to the > SUBSCRIBE are > ignored since the dialog is in established state. Isn't this > a problem? the > route-set is lost. > > I appreciate some clarifications. > > Regards, > Hisham > > > > -----Original Message----- > > From: ext hisham.khartabil@nokia.com > > [mailto:hisham.khartabil@nokia.com] > > Sent: Wednesday, March 12, 2003 5:37 PM > > To: sip@ietf.org > > Subject: [Sip] NOTIFY establishes a dialog > > > > > > In RFC3265, it is mentioned that NOTIFY can certainly > > establish a dialog if it arrives before the 200 of a > > SUBSCRIBE. What happens when the 200 for the SUBSCRIBE now > > arrives with record-route headers? Does the route-set get > > updated? (keeping in mind that the dialog is now in the > > established state). > > > > Regards, > > Hisham > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Wed Mar 19 23:18:30 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23626 for ; Wed, 19 Mar 2003 23:18:30 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2K4aBg06567 for sip-archive@odin.ietf.org; Wed, 19 Mar 2003 23:36:11 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2K4KwO05771; Wed, 19 Mar 2003 23:20:58 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2JAnVO18795 for ; Wed, 19 Mar 2003 05:49:31 -0500 Received: from iisc.ernet.in (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18230 for ; Wed, 19 Mar 2003 05:31:36 -0500 (EST) Received: from eis.iisc.ernet.in (eis.iisc.ernet.in [144.16.64.5]) by iisc.ernet.in (8.9.2/8.9.0) with SMTP id QAA09028; Wed, 19 Mar 2003 16:07:08 +0530 (IST) Received: by eis.iisc.ernet.in (SMI-8.6/SMI-4.1) id QAA09756; Wed, 19 Mar 2003 16:03:45 +0530 From: anand@eis.iisc.ernet.in (SVR Anand) Message-Id: <200303191033.QAA09756@eis.iisc.ernet.in> Subject: Re: Ri: [Sip] SIP proxy network To: loretosa@vodafone.it Date: Wed, 19 Mar 2003 16:03:44 +0530 (GMT+05:30) Cc: sip@ietf.org In-Reply-To: from "loretosa@vodafone.it" at Mar 18, 2003 11:46:37 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit The kind of information the proxies exchange should enable the UA or local proxy to dynamically locate and choose where to forward say,INVITE to. Since the information contained within proxies is at the application level I am thinking if an application level and perhaps text based routing protocol is necessary. > > I'm not sure about your question, > are you asking about the possibility for UA or an > inBound Proxy to choose the best way where send > a message (like INVITE)? > > > > Hi, > > > > Not sure if I am sending my mail to the proper mailing list. > > > > Just a wild thought. Can I think of network of SIP proxies connected in some > > way dynamically exchanging messages in order to assist in forwarding of say, > > INVITES to an appropriate proxy ? Just like OSPF for link state information, > > proxy network for say proxy configuration information exchange ? > > > > Please let me know if I am talking sense. > > > > Anand > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > > Per registrarti gratuitamente a Vodafone Mail vai su www.190.it > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Thu Mar 20 00:03:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25555 for ; Thu, 20 Mar 2003 00:03:25 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2K5L7f10289 for sip-archive@odin.ietf.org; Thu, 20 Mar 2003 00:21:07 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2K5CiO09704; Thu, 20 Mar 2003 00:12:44 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2K59cO09552 for ; Thu, 20 Mar 2003 00:09:38 -0500 Received: from wiprom2mx1.wipro.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25063 for ; Wed, 19 Mar 2003 23:51:19 -0500 (EST) Received: from m2vwall5.wipro.com (m2vwall5.wipro.com [10.115.50.5]) by wiprom2mx1.wipro.com (8.11.3/8.11.3) with SMTP id h2K4rW807731 for ; Thu, 20 Mar 2003 10:23:32 +0530 (IST) Received: from blr-m1-msg.wipro.com ([10.115.50.99]) by blr-m1-bh1.wipro.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 20 Mar 2003 10:23:27 +0530 Received: from Ganesh ([10.115.6.216]) by blr-m1-msg.wipro.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 20 Mar 2003 10:23:27 +0530 Subject: RE: [Sip] NOTIFY establishes a dialog From: Ganesh Sivaraman To: ganesh.sivaraman@wipro.com Cc: sip@ietf.org In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB7FE73E7@esebe019.ntc.nokia.com> References: <2038BCC78B1AD641891A0D1AE133DBB7FE73E7@esebe019.ntc.nokia.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 20 Mar 2003 10:25:37 +0530 Message-Id: <1048136137.18805.25.camel@Ganesh> Mime-Version: 1.0 X-OriginalArrivalTime: 20 Mar 2003 04:53:27.0231 (UTC) FILETIME=[A51DFCF0:01C2EE9C] Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Hisham, I'd posted the same question about setting dialog-state (route-set etc.) and I got the following response: It says: "RFC 3265 augments 3261, in that the dialog in this case can be created either by a response to SUBSCRIBE or by NOTIFY". So that would mean that the route-set could be constructed with Route-headers (present in NOTIFY) also. Is this a correct assumption? A word from the authors of the RFC on this would help bring more clarity. Regards Ganesh On Thu, 2003-03-20 at 04:17, hisham.khartabil@nokia.com wrote: > I have a few related questions/comments: > > - A 180 response to a request (like INVITE) establishes a dialog. This 180 response carries record-route headers and therefore sets the route-set. The 200 response to the request might also carry record-route headers. The dialog transitions to confirmed state, but I assume the route-set does not get updated using the record-route headers in the 200 response since the dialog is established already. Is this a correct assumption? should the UAS send record-route headers at all in the 200 if it sent a 1xx already? > > Should there be a mandate that 1xx and 2xx response carry the same record-route headers? You would assume that this happens naturally at the UAS, but proxies may play around with the record-route headers. > > - In the NOTIFY problem below, the NOTIFY establishes the dialog, but does not carry record-route headers. If the same assumption is made as above, the record-route headers appearing in the 200 response to the SUBSCRIBE are ignored since the dialog is in established state. Isn't this a problem? the route-set is lost. > > I appreciate some clarifications. > > Regards, > Hisham > > > > -----Original Message----- > > From: ext hisham.khartabil@nokia.com > > [mailto:hisham.khartabil@nokia.com] > > Sent: Wednesday, March 12, 2003 5:37 PM > > To: sip@ietf.org > > Subject: [Sip] NOTIFY establishes a dialog > > > > > > In RFC3265, it is mentioned that NOTIFY can certainly > > establish a dialog if it arrives before the 200 of a > > SUBSCRIBE. What happens when the 200 for the SUBSCRIBE now > > arrives with record-route headers? Does the route-set get > > updated? (keeping in mind that the dialog is now in the > > established state). > > > > Regards, > > Hisham > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Thu Mar 20 00:12:47 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25952 for ; Thu, 20 Mar 2003 00:12:47 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2K5UTn10664 for sip-archive@odin.ietf.org; Thu, 20 Mar 2003 00:30:29 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2K5NPO10378; Thu, 20 Mar 2003 00:23:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2K5KvO10277 for ; Thu, 20 Mar 2003 00:20:57 -0500 Received: from hss.hns.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25538 for ; Thu, 20 Mar 2003 00:02:41 -0500 (EST) From: sshetti@hss.hns.com Received: from sampark.hss.hns.com (sampark [139.85.229.22]) by hss.hns.com (8.11.6/8.11.2) with SMTP id h2K4T3a17962; Thu, 20 Mar 2003 09:59:07 +0530 Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 65256CEF.001BC456 ; Thu, 20 Mar 2003 10:33:17 +0530 X-Lotus-FromDomain: HSSBLR To: Kevin Lingle cc: Jonathan Rosenberg , sip@ietf.org, Dave Walker Message-ID: <65256CEF.001BC43B.00@sampark.hss.hns.com> Date: Thu, 20 Mar 2003 10:33:16 +0530 Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-mib-05.txt Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , We too have sip-mib implementation in our product. Following is my view with respect to sipTransactionTable: 1. Maintaining this table info in the system is not 'simple and straight forward'. Reason: Data involved are very volatile. Moreover it requires indexing the transactions which themselves are volatile (destroyed any time). 2. This information is usually obtained (if et-all obtained!) will be via GET-BULK operation. To support GET-BULK to retrieve information specific to all transactions has momentory performance impact on the Server. There are issues of thread-safety between GET-BULK and the transaction handling operation. 3. Same information can be obtained either through protocol trace logs or CDR (call detail records). I feel sip-mib should not have tables involving volatile data. I also feel sipCurrentTransTable is not useful. May be TRAP objects based on sipCurrentTransTable, will be more useful to SNMP admin. I think sip-mib has captured very elaborately on following things. 1. Server Administration/Configuration 2. User data management 3. Statistics I really appreciate the above factor. I have some comments on following MIB fields, please clarify them as my understanding may differ from the auther's of sip-mib. 1. "sipMaxSessions" of SipCommonCfgEntry: This is a READ-ONLY property supplied by the SIP-ENTITY. As per the definition the entity has to determine what is the maximum load it can handle. Again, the above factor depends on the hardware/software configuration of the deployment platform. Do we expect for instance a SIP-Proxy to run some algorithm/load itself to find out this value? I feel this field may not be useful. 2. "sipTransportSnd" of SipPortEntry: I donot understand how this field is utilized in SIP, specific to a port number. "sipTransportRcv" can be understood as for associated port number the SIP entity will receive message for TRANSPORTS that are enabled in this field. 3. "sipPgpVersion" of SipServerCfgEntry, "sipPgpPrivateKey" of SipProxyCfgEntry: PGP is deprecated in SIP. Can these be removed? There may be more things specific to PGP. 4. "sipServerRespectUAAction" of SipServerCfgEntry: This mentions action parameter specific operation in the proxy which is deprecated in SIP. Can we deprecate here also? 5. "sipRegMaxUsers" of "SipRegCfgEntry": This is a READ-ONLY field which is supposed to be given out by REGISTRAR as what is the number of users does it support. Again, what is the criteria with which registrar arrives at this data. This data again depends on deployment platform such as capacity of the database etc. This data too may not be useful to administrator. This value is either known to the admin or enforced by admin on REGISTRAR. Therefore keeping it as READ-ONLY has no purpose. 6. "sipContactAction" of SipContactEntry: Again deprecated by SIP. Can we deprecate here too? 7. "sipContactRetryAfter" of SipContactEntry: Again deprecated by SIP. Can we deprecate here too? 8. Transaction timer specific configuration are based on pre-bis05 drafts. They have to be updated according to latest RFC. I think action-item is already initiated for post mib-05 drafts. Thanks and Regards, Shrinivas Shetti Kevin Lingle on 03/19/2003 09:10:17 PM To: Jonathan Rosenberg cc: sip@ietf.org, Dave Walker (bcc: Shrinivas Shetti/HSSBLR) Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-mib-05.txt Jonathan Rosenberg wrote: > > Kevin Lingle wrote: > > >>I have begun to look at the mib a bit, and I am a bit concerned that > >>there is far too much information exposed, in terms of statistics, at > >>least. I have to apologize for raising this so late in the game, but it > >>is only recently that my day job has brought me into OAMP areas. > > > > > > not sure if the above reference to statistics is directly related > > to your comment on sipTransactionTable below or not. > > Yes. > > > if not, are there > > other statistics that you feel fall into the category or > > exposing far too much information? > > I want to look some more and provide some additional comments. that would be great. > > > > > > >>One item that struck me as particularly demanding on an implementation > >>is the sipTransactionTable. There is a huge amount of work in > >>maintaining this table. I really doubt people will want to implement it. > > > > > > i had similar feedback from others when support of the sipTransactionTable > > was being considered by a project. the effort involved in supporting > > the table was a problem. > > > > we can focus some discussion on the viability of the table during wg last call. > > Well, discussion can happen any time. Its happening now, in this email > thread. I dont know what else you are expecting. sorry. didn't mean to imply what came across. we can definitely discuss it now. i'm just not used to actually having active discussion of the mib. i'm used to getting one or two sporatic comments and only having focused discussion during last call - when someone is forced to review the mib ;) > I don't think the table > is viable. You had similar feedback. Seems like a clear cut resolution > to me. not that i don't take your point of view as very significant, i do. i was hoping that others might concur before we decide to remove the table. the table has been in every revision of the mib, so it has been reviewed multiple times by multiple people... no one - until now has recommended it come out. i guess i had taken that as acceptance of it's potential usefulness to someone. my case of one project finding it questionable does not necessarily make a case for it's removal. we determined that support was feasible but not all that useful for our platform. implementation experience with a mib usually decides such things and we don't have much (any?) feedback in that area (not likely to until the mibs are in an rfc). still, if we can resolve the question of usefulness now it would be better than to have to revise the mib (ie, rfc) and deprecate objects found - through implementation experience - to be useless. > > > i'd rather do that than to yank the table w/out further discussion. > > *This* is the discussion. agreed. > > > at the very least, we can definitely make the table optional. > > right now it appears to be in a mandatory group - which seem wrong to me anyway. > > Mandatory is definitely wrong. I am not even sure optional is useful. > > So - here is the question. What is the bar for putting something in the > MIB? At one extreme, every piece of state managed by a server could be > in the mib. At the other extreme, there is nothing, or a single summary > statistic. I think a reasonable bar, is that there should be clear value > in monitoring that information, from the perspective of fault and > performance management in particular. If you cannot demonstrate such a > use, it should be out. > > I cannot think of a reason that I would want, from an operations center, > to monitor the current set of transactions held in the system. Thus, I > think it should be out. it's hard for me to justify or defend the existence of this table as i was not the original author of it. but for the sake of discussion... is there no value from a troubleshooting perspective? you mentioned that this information is likely logged for offline analysis - not real-time. are transactions generally occuring too fast for real-time analysis to be of worth? it would seem to me that unless you know specifically which transactions are of interest to you, it would be hard to use this table for anything. the table is defintely not a logging mechanism as transactions will not persist for any historically significant time. from a performance mgmt point of view... could the increase in entries in this table be used to gain insight into congestion in this or other parts of the sip network? even if that were the case, the simple sipCurrentTransactions gauge object would provide similar insight (to congestion at least). perhaps the to/from details in the table would lend some more insight to problems elsewhere in the network? i'm not sure. dave walker was the original author of this table, so maybe he can offer some insight. dave? i did find one old comment related to this table squirreled away in some old emails.... Kurt Robohm wrote: > > sipCurrentTransacations Does this reflect number of > calls in progress? > Intent of objects in table to > sipTransactionTable provide real time info on > number of calls being handled > real time? Dave Walker responded: > Transactions aren't calls. The intent, as mentioned in Adelaide, > is to evolve the transaction table to a call leg table (probably > for UAs only). This hasn't been resolved yet, so no real changes > were made. i can't find any further discussion by dave (or others) in subsequent revisions of the draft to work out any further evolution of this table. only minor comments related to the table - none questioning its existence. dave's involvement in the last couple of revisions of the draft have been nil. so perhaps the table is an articfact of an idea that was not fully conceived or fleshed out. that would lend itself to removal imo. kevin > > Is not our aim to take things out of protocols until we can't take out > any more, rather than the other way around? > > -Jonathan R. > > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Kevin R. Lingle 919.392.2029 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Thu Mar 20 01:00:44 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27070 for ; Thu, 20 Mar 2003 01:00:39 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2K6INM14211 for sip-archive@odin.ietf.org; Thu, 20 Mar 2003 01:18:23 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2K6GnO14159; Thu, 20 Mar 2003 01:16:49 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2K6CYO13814 for ; Thu, 20 Mar 2003 01:12:34 -0500 Received: from dyn-tx-arch-crash.dfw.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26966 for ; Thu, 20 Mar 2003 00:54:00 -0500 (EST) Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h2K5u3932341; Wed, 19 Mar 2003 23:56:03 -0600 Subject: RE: [Sip] NOTIFY establishes a dialog From: Robert Sparks To: Ganesh Sivaraman , hisham.khartabil@nokia.com Cc: sip@ietf.org In-Reply-To: <1048136137.18805.25.camel@Ganesh> References: <2038BCC78B1AD641891A0D1AE133DBB7FE73E7@esebe019.ntc.nokia.com> <1048136137.18805.25.camel@Ganesh> Content-Type: text/plain Message-Id: <1048139722.954.6.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 19 Mar 2003 21:55:22 -0800 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit response to one of the questions inline: On Wed, 2003-03-19 at 20:55, Ganesh Sivaraman wrote: > Hi Hisham, > I'd posted the same question about setting dialog-state (route-set > etc.) and I got the following response: > > > It says: > "RFC 3265 augments 3261, in that the dialog in this case can be created > either by a response to SUBSCRIBE or by NOTIFY". > > So that would mean that the route-set could be constructed with > Route-headers (present in NOTIFY) also. Is this a correct assumption? > > A word from the authors of the RFC on this would help bring more > clarity. > > Regards > Ganesh > > On Thu, 2003-03-20 at 04:17, hisham.khartabil@nokia.com wrote: > > I have a few related questions/comments: > > > > - A 180 response to a request (like INVITE) establishes a dialog. This 180 response carries record-route headers and therefore sets the route-set. The 200 response to the request might also carry record-route headers. The dialog transitions to confirmed state, but I assume the route-set does not get updated using the record-route headers in the 200 response since the dialog is established already. Is this a correct assumption? should the UAS send record-route headers at all in the 200 if it sent a 1xx already? >From rfc3261 page 82: If the dialog identifier in the 2xx response matches the dialog identifier of an existing dialog, the dialog MUST be transitioned to the "confirmed" state, and the route set for the dialog MUST be recomputed based on the 2xx response using the procedures of Section 12.2.1.2. Otherwise, a new dialog in the "confirmed" state MUST be constructed using the procedures of Section 12.1.2. In context, you'll see the "existing dialog" above is an "early dialog". > > > > Should there be a mandate that 1xx and 2xx response carry the same record-route headers? You would assume that this happens naturally at the UAS, but proxies may play around with the record-route headers. > > > > - In the NOTIFY problem below, the NOTIFY establishes the dialog, but does not carry record-route headers. If the same assumption is made as above, the record-route headers appearing in the 200 response to the SUBSCRIBE are ignored since the dialog is in established state. Isn't this a problem? the route-set is lost. > > > > I appreciate some clarifications. > > > > Regards, > > Hisham > > > > > > > -----Original Message----- > > > From: ext hisham.khartabil@nokia.com > > > [mailto:hisham.khartabil@nokia.com] > > > Sent: Wednesday, March 12, 2003 5:37 PM > > > To: sip@ietf.org > > > Subject: [Sip] NOTIFY establishes a dialog > > > > > > > > > In RFC3265, it is mentioned that NOTIFY can certainly > > > establish a dialog if it arrives before the 200 of a > > > SUBSCRIBE. What happens when the 200 for the SUBSCRIBE now > > > arrives with record-route headers? Does the route-set get > > > updated? (keeping in mind that the dialog is now in the > > > established state). > > > > > > Regards, > > > Hisham > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > Use sipping@ietf.org for new developments on the application of sip > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Thu Mar 20 01:21:08 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27488 for ; Thu, 20 Mar 2003 01:21:02 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2K6clZ15793 for sip-archive@odin.ietf.org; Thu, 20 Mar 2003 01:38:47 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2K6bYO15557; Thu, 20 Mar 2003 01:37:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2K6WVO14694 for ; Thu, 20 Mar 2003 01:32:31 -0500 Received: from mail4.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27311 for ; Thu, 20 Mar 2003 01:13:56 -0500 (EST) Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h2K6FsYk012380; Thu, 20 Mar 2003 01:15:54 -0500 (EST) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Thu, 20 Mar 2003 00:15:57 -0600 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A645B4@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'hisham.khartabil@nokia.com'" , sip@ietf.org Subject: RE: [Sip] NOTIFY establishes a dialog Date: Thu, 20 Mar 2003 00:15:51 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > > In RFC3265, it is mentioned that NOTIFY can certainly > establish a dialog if it arrives before the 200 of a > SUBSCRIBE. What happens when the 200 for the SUBSCRIBE now > arrives with record-route headers? Does the route-set get > updated? (keeping in mind that the dialog is now in the > established state). Not if it's part of the same dialog as the aforementioned NOTIFY. In the case that the SUBSCRIBE 200 doesn't match any dialog that's already been established (e.g. by a NOTIFY), then it *does* establish a dialog. If the event package doesn't allow forking, such a dialog conceptually terminates after the the subscriber 481s the corresponding NOTIFY. > the NOTIFY establishes the dialog, but does not carry record-route > headers. If the same assumption is made as above, the record-route > headers appearing in the 200 response to the SUBSCRIBE are ignored > since the dialog is in established state. Isn't this a problem? the > route-set is lost. Section 3.1.5 of 3265 clearly states: If a proxy wishes to see all of the SUBSCRIBE and NOTIFY requests for a given dialog, it MUST record-route the initial SUBSCRIBE and any dialog-establishing NOTIFY requests. Such proxies SHOULD also record-route all other SUBSCRIBE and NOTIFY requests. A consequence of this clause is that a proxy which Record-Routes the 200 response will also Record-Route the NOTIFY in the same dialog. A further consequence is that the route set in a SUBSCRIBE 200 and that of a NOTIFY in the same dialog will always be identical. /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 mailnull@www1.ietf.org Thu Mar 20 01:30:30 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27736 for ; Thu, 20 Mar 2003 01:30:25 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2K6m8P16285 for sip-archive@odin.ietf.org; Thu, 20 Mar 2003 01:48:08 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2K6l0O16234; Thu, 20 Mar 2003 01:47:00 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2K6giO16114 for ; Thu, 20 Mar 2003 01:42:44 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27589 for ; Thu, 20 Mar 2003 01:24:07 -0500 (EST) From: hisham.khartabil@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.5/Switch-2.2.5) with ESMTP id h2K6U1u14620 for ; Thu, 20 Mar 2003 08:30:01 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 20 Mar 2003 08:19:55 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 20 Mar 2003 08:19:50 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sip] NOTIFY establishes a dialog Date: Thu, 20 Mar 2003 08:19:50 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7FE73F0@esebe019.ntc.nokia.com> Thread-Topic: [Sip] NOTIFY establishes a dialog Thread-Index: AcLupWwJOQYcZHk+TAGu/V19WZmDwQAApXOQ To: , Cc: X-OriginalArrivalTime: 20 Mar 2003 06:19:50.0894 (UTC) FILETIME=[B6D230E0:01C2EEA8] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2K6gsO16118 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit This sounds like a solution to the first problem. I guess I couldn't find the text because it was in the wrong section. May I suggest a bug report specifying moving the text to section 12. The other problem with NOTIFY can be solved by specifying that a NOTIFY establishes an early dialog. Is that ok? bug report? Regards, Hisham > -----Original Message----- > From: ext Robert Sparks [mailto:rsparks@dynamicsoft.com] > Sent: Thursday, March 20, 2003 7:55 AM > To: Ganesh Sivaraman; Khartabil Hisham (NMP/Helsinki) > Cc: sip@ietf.org > Subject: RE: [Sip] NOTIFY establishes a dialog > > > response to one of the questions inline: > > On Wed, 2003-03-19 at 20:55, Ganesh Sivaraman wrote: > > Hi Hisham, > > I'd posted the same question about setting dialog-state (route-set > > etc.) and I got the following response: > > > February/004569.html> > > > > It says: > > "RFC 3265 augments 3261, in that the dialog in this case > can be created > > either by a response to SUBSCRIBE or by NOTIFY". > > > > So that would mean that the route-set could be constructed with > > Route-headers (present in NOTIFY) also. Is this a correct > assumption? > > > > A word from the authors of the RFC on this would help bring more > > clarity. > > > > Regards > > Ganesh > > > > On Thu, 2003-03-20 at 04:17, hisham.khartabil@nokia.com wrote: > > > I have a few related questions/comments: > > > > > > - A 180 response to a request (like INVITE) establishes a > dialog. This 180 response carries record-route headers and > therefore sets the route-set. The 200 response to the request > might also carry record-route headers. The dialog transitions > to confirmed state, but I assume the route-set does not get > updated using the record-route headers in the 200 response > since the dialog is established already. Is this a correct > assumption? should the UAS send record-route headers at all > in the 200 if it sent a 1xx already? > > >From rfc3261 page 82: > > If the dialog identifier in the 2xx response matches the dialog > identifier of an existing dialog, the dialog MUST be > transitioned to > the "confirmed" state, and the route set for the dialog MUST be > recomputed based on the 2xx response using the procedures > of Section > 12.2.1.2. Otherwise, a new dialog in the "confirmed" state MUST be > constructed using the procedures of Section 12.1.2. > > In context, you'll see the "existing dialog" above is an > "early dialog". > > > > > > > Should there be a mandate that 1xx and 2xx response carry > the same record-route headers? You would assume that this > happens naturally at the UAS, but proxies may play around > with the record-route headers. > > > > > > - In the NOTIFY problem below, the NOTIFY establishes the > dialog, but does not carry record-route headers. If the same > assumption is made as above, the record-route headers > appearing in the 200 response to the SUBSCRIBE are ignored > since the dialog is in established state. Isn't this a > problem? the route-set is lost. > > > > > > I appreciate some clarifications. > > > > > > Regards, > > > Hisham > > > > > > > > > > -----Original Message----- > > > > From: ext hisham.khartabil@nokia.com > > > > [mailto:hisham.khartabil@nokia.com] > > > > Sent: Wednesday, March 12, 2003 5:37 PM > > > > To: sip@ietf.org > > > > Subject: [Sip] NOTIFY establishes a dialog > > > > > > > > > > > > In RFC3265, it is mentioned that NOTIFY can certainly > > > > establish a dialog if it arrives before the 200 of a > > > > SUBSCRIBE. What happens when the 200 for the SUBSCRIBE now > > > > arrives with record-route headers? Does the route-set get > > > > updated? (keeping in mind that the dialog is now in the > > > > established state). > > > > > > > > Regards, > > > > Hisham > > > > _______________________________________________ > > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > > This list is for NEW development of the core SIP Protocol > > > > Use sip-implementors@cs.columbia.edu for questions on > current sip > > > > Use sipping@ietf.org for new developments on the > application of sip > > > > > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > Use sipping@ietf.org for new developments on the > application of sip > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Thu Mar 20 01:49:07 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28159 for ; Thu, 20 Mar 2003 01:49:02 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2K76jO20312 for sip-archive@odin.ietf.org; Thu, 20 Mar 2003 02:06:45 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2K760O19492; Thu, 20 Mar 2003 02:06:00 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2K70iO16804 for ; Thu, 20 Mar 2003 02:00:44 -0500 Received: from dyn-tx-arch-crash.dfw.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28056 for ; Thu, 20 Mar 2003 01:42:10 -0500 (EST) Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h2K6iA900509; Thu, 20 Mar 2003 00:44:10 -0600 Subject: RE: [Sip] NOTIFY establishes a dialog From: Robert Sparks To: hisham.khartabil@nokia.com Cc: ganesh.sivaraman@wipro.com, sip@ietf.org In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB7FE73F0@esebe019.ntc.nokia.com> References: <2038BCC78B1AD641891A0D1AE133DBB7FE73F0@esebe019.ntc.nokia.com> Content-Type: text/plain Message-Id: <1048142608.1172.23.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 19 Mar 2003 22:43:29 -0800 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit A NOTIFY that beats a 200 OK establishes a full-blown established dialog, not an early one. If the 200 dialog identifiers match the NOTIFY, the route set will not be updated. If the 200 identifies some other dialog, then the dialog established by the NOTIFY continues to exist - state unchanged. This is covered in 3.3.4 of 3265 - the first of a NOTIFY or a 200 with a fully qualified dialog identifier establishes a dialog (and the corresponding route set). Please read that section again - if you still think it's not clear, propose text. RjS On Wed, 2003-03-19 at 22:19, hisham.khartabil@nokia.com wrote: > This sounds like a solution to the first problem. I guess I couldn't find the text because it was in the wrong section. May I suggest a bug report specifying moving the text to section 12. > > The other problem with NOTIFY can be solved by specifying that a NOTIFY establishes an early dialog. Is that ok? bug report? > > Regards, > Hisham > > > -----Original Message----- > > From: ext Robert Sparks [mailto:rsparks@dynamicsoft.com] > > Sent: Thursday, March 20, 2003 7:55 AM > > To: Ganesh Sivaraman; Khartabil Hisham (NMP/Helsinki) > > Cc: sip@ietf.org > > Subject: RE: [Sip] NOTIFY establishes a dialog > > > > > > response to one of the questions inline: > > > > On Wed, 2003-03-19 at 20:55, Ganesh Sivaraman wrote: > > > Hi Hisham, > > > I'd posted the same question about setting dialog-state (route-set > > > etc.) and I got the following response: > > > > > > February/004569.html> > > > > > > It says: > > > "RFC 3265 augments 3261, in that the dialog in this case > > can be created > > > either by a response to SUBSCRIBE or by NOTIFY". > > > > > > So that would mean that the route-set could be constructed with > > > Route-headers (present in NOTIFY) also. Is this a correct > > assumption? > > > > > > A word from the authors of the RFC on this would help bring more > > > clarity. > > > > > > Regards > > > Ganesh > > > > > > On Thu, 2003-03-20 at 04:17, hisham.khartabil@nokia.com wrote: > > > > I have a few related questions/comments: > > > > > > > > - A 180 response to a request (like INVITE) establishes a > > dialog. This 180 response carries record-route headers and > > therefore sets the route-set. The 200 response to the request > > might also carry record-route headers. The dialog transitions > > to confirmed state, but I assume the route-set does not get > > updated using the record-route headers in the 200 response > > since the dialog is established already. Is this a correct > > assumption? should the UAS send record-route headers at all > > in the 200 if it sent a 1xx already? > > > > >From rfc3261 page 82: > > > > If the dialog identifier in the 2xx response matches the dialog > > identifier of an existing dialog, the dialog MUST be > > transitioned to > > the "confirmed" state, and the route set for the dialog MUST be > > recomputed based on the 2xx response using the procedures > > of Section > > 12.2.1.2. Otherwise, a new dialog in the "confirmed" state MUST be > > constructed using the procedures of Section 12.1.2. > > > > In context, you'll see the "existing dialog" above is an > > "early dialog". > > > > > > > > > > Should there be a mandate that 1xx and 2xx response carry > > the same record-route headers? You would assume that this > > happens naturally at the UAS, but proxies may play around > > with the record-route headers. > > > > > > > > - In the NOTIFY problem below, the NOTIFY establishes the > > dialog, but does not carry record-route headers. If the same > > assumption is made as above, the record-route headers > > appearing in the 200 response to the SUBSCRIBE are ignored > > since the dialog is in established state. Isn't this a > > problem? the route-set is lost. > > > > > > > > I appreciate some clarifications. > > > > > > > > Regards, > > > > Hisham > > > > > > > > > > > > > -----Original Message----- > > > > > From: ext hisham.khartabil@nokia.com > > > > > [mailto:hisham.khartabil@nokia.com] > > > > > Sent: Wednesday, March 12, 2003 5:37 PM > > > > > To: sip@ietf.org > > > > > Subject: [Sip] NOTIFY establishes a dialog > > > > > > > > > > > > > > > In RFC3265, it is mentioned that NOTIFY can certainly > > > > > establish a dialog if it arrives before the 200 of a > > > > > SUBSCRIBE. What happens when the 200 for the SUBSCRIBE now > > > > > arrives with record-route headers? Does the route-set get > > > > > updated? (keeping in mind that the dialog is now in the > > > > > established state). > > > > > > > > > > Regards, > > > > > Hisham > > > > > _______________________________________________ > > > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > > > This list is for NEW development of the core SIP Protocol > > > > > Use sip-implementors@cs.columbia.edu for questions on > > current sip > > > > > Use sipping@ietf.org for new developments on the > > application of sip > > > > > > > > > _______________________________________________ > > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > > This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Thu Mar 20 02:02:46 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01125 for ; Thu, 20 Mar 2003 02:02:41 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2K7KEG28378 for sip-archive@odin.ietf.org; Thu, 20 Mar 2003 02:20:14 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2K7J1O28294; Thu, 20 Mar 2003 02:19:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2K7BXO26767 for ; Thu, 20 Mar 2003 02:11:33 -0500 Received: from dyn-tx-arch-crash.dfw.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28217 for ; Thu, 20 Mar 2003 01:52:59 -0500 (EST) Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h2K6sx900665; Thu, 20 Mar 2003 00:54:59 -0600 Subject: RE: [Sip] NOTIFY establishes a dialog From: Robert Sparks To: hisham.khartabil@nokia.com Cc: ganesh.sivaraman@wipro.com, sip@ietf.org In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB7FE73F0@esebe019.ntc.nokia.com> References: <2038BCC78B1AD641891A0D1AE133DBB7FE73F0@esebe019.ntc.nokia.com> Content-Type: text/plain Message-Id: <1048143258.1172.26.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 19 Mar 2003 22:54:18 -0800 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Wed, 2003-03-19 at 22:19, hisham.khartabil@nokia.com wrote: > This sounds like a solution to the first problem. I guess I couldn't find the text because it was in the wrong section. May I suggest a bug report specifying moving the text to section 12. Added as bug 703. > The other problem with NOTIFY can be solved by specifying that a NOTIFY establishes an early dialog. Is that ok? bug report? > > Regards, > Hisham > > > -----Original Message----- > > From: ext Robert Sparks [mailto:rsparks@dynamicsoft.com] > > Sent: Thursday, March 20, 2003 7:55 AM > > To: Ganesh Sivaraman; Khartabil Hisham (NMP/Helsinki) > > Cc: sip@ietf.org > > Subject: RE: [Sip] NOTIFY establishes a dialog > > > > > > response to one of the questions inline: > > > > On Wed, 2003-03-19 at 20:55, Ganesh Sivaraman wrote: > > > Hi Hisham, > > > I'd posted the same question about setting dialog-state (route-set > > > etc.) and I got the following response: > > > > > > February/004569.html> > > > > > > It says: > > > "RFC 3265 augments 3261, in that the dialog in this case > > can be created > > > either by a response to SUBSCRIBE or by NOTIFY". > > > > > > So that would mean that the route-set could be constructed with > > > Route-headers (present in NOTIFY) also. Is this a correct > > assumption? > > > > > > A word from the authors of the RFC on this would help bring more > > > clarity. > > > > > > Regards > > > Ganesh > > > > > > On Thu, 2003-03-20 at 04:17, hisham.khartabil@nokia.com wrote: > > > > I have a few related questions/comments: > > > > > > > > - A 180 response to a request (like INVITE) establishes a > > dialog. This 180 response carries record-route headers and > > therefore sets the route-set. The 200 response to the request > > might also carry record-route headers. The dialog transitions > > to confirmed state, but I assume the route-set does not get > > updated using the record-route headers in the 200 response > > since the dialog is established already. Is this a correct > > assumption? should the UAS send record-route headers at all > > in the 200 if it sent a 1xx already? > > > > >From rfc3261 page 82: > > > > If the dialog identifier in the 2xx response matches the dialog > > identifier of an existing dialog, the dialog MUST be > > transitioned to > > the "confirmed" state, and the route set for the dialog MUST be > > recomputed based on the 2xx response using the procedures > > of Section > > 12.2.1.2. Otherwise, a new dialog in the "confirmed" state MUST be > > constructed using the procedures of Section 12.1.2. > > > > In context, you'll see the "existing dialog" above is an > > "early dialog". > > > > > > > > > > Should there be a mandate that 1xx and 2xx response carry > > the same record-route headers? You would assume that this > > happens naturally at the UAS, but proxies may play around > > with the record-route headers. > > > > > > > > - In the NOTIFY problem below, the NOTIFY establishes the > > dialog, but does not carry record-route headers. If the same > > assumption is made as above, the record-route headers > > appearing in the 200 response to the SUBSCRIBE are ignored > > since the dialog is in established state. Isn't this a > > problem? the route-set is lost. > > > > > > > > I appreciate some clarifications. > > > > > > > > Regards, > > > > Hisham > > > > > > > > > > > > > -----Original Message----- > > > > > From: ext hisham.khartabil@nokia.com > > > > > [mailto:hisham.khartabil@nokia.com] > > > > > Sent: Wednesday, March 12, 2003 5:37 PM > > > > > To: sip@ietf.org > > > > > Subject: [Sip] NOTIFY establishes a dialog > > > > > > > > > > > > > > > In RFC3265, it is mentioned that NOTIFY can certainly > > > > > establish a dialog if it arrives before the 200 of a > > > > > SUBSCRIBE. What happens when the 200 for the SUBSCRIBE now > > > > > arrives with record-route headers? Does the route-set get > > > > > updated? (keeping in mind that the dialog is now in the > > > > > established state). > > > > > > > > > > Regards, > > > > > Hisham > > > > > _______________________________________________ > > > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > > > This list is for NEW development of the core SIP Protocol > > > > > Use sip-implementors@cs.columbia.edu for questions on > > current sip > > > > > Use sipping@ietf.org for new developments on the > > application of sip > > > > > > > > > _______________________________________________ > > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > > This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Thu Mar 20 11:02:07 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22791 for ; Thu, 20 Mar 2003 11:02:07 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2KGK2330689 for sip-archive@odin.ietf.org; Thu, 20 Mar 2003 11:20:02 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2KGJCO30621; Thu, 20 Mar 2003 11:19:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2KGAnO30342 for ; Thu, 20 Mar 2003 11:10:49 -0500 Received: from sj-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22411 for ; Thu, 20 Mar 2003 10:52:22 -0500 (EST) Received: from whoami-new.cisco.com (IDENT:mirapoint@whoami-new.cisco.com [64.101.128.102]) by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2KFsT4c009182; Thu, 20 Mar 2003 07:54:29 -0800 (PST) Received: from ARUNVENKW2Kl (arunvenk-w2kl-2.cisco.com [64.101.164.75]) by whoami-new.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with SMTP id ABB61307; Thu, 20 Mar 2003 09:54:28 -0600 (CST) From: "Arunachalam Venkatraman" To: "Robert Sparks" Cc: Subject: RE: [Sip] NOTIFY establishes a dialog Date: Thu, 20 Mar 2003 09:54:28 -0600 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 In-Reply-To: <1048139722.954.6.camel@RjS.localdomain> Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Robert Can you explain the reasoning behind the section from RFC3261 that you have quoted below? I would think the Record-Route headers on the 1xx and 200 will be identical since the responses would traverse (backwards) the same path that the INVITE took, using the same VIA set. Why should one recompute the Route Set? The only thing that may change is the Contact, isn't it? Venkat -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Robert Sparks Sent: Wednesday, March 19, 2003 11:55 PM To: Ganesh Sivaraman; hisham.khartabil@nokia.com Cc: sip@ietf.org Subject: RE: [Sip] NOTIFY establishes a dialog response to one of the questions inline: On Wed, 2003-03-19 at 20:55, Ganesh Sivaraman wrote: > Hi Hisham, > I'd posted the same question about setting dialog-state (route-set > etc.) and I got the following response: > > > It says: > "RFC 3265 augments 3261, in that the dialog in this case can be created > either by a response to SUBSCRIBE or by NOTIFY". > > So that would mean that the route-set could be constructed with > Route-headers (present in NOTIFY) also. Is this a correct assumption? > > A word from the authors of the RFC on this would help bring more > clarity. > > Regards > Ganesh > > On Thu, 2003-03-20 at 04:17, hisham.khartabil@nokia.com wrote: > > I have a few related questions/comments: > > > > - A 180 response to a request (like INVITE) establishes a dialog. This 180 response carries record-route headers and therefore sets the route-set. The 200 response to the request might also carry record-route headers. The dialog transitions to confirmed state, but I assume the route-set does not get updated using the record-route headers in the 200 response since the dialog is established already. Is this a correct assumption? should the UAS send record-route headers at all in the 200 if it sent a 1xx already? >From rfc3261 page 82: If the dialog identifier in the 2xx response matches the dialog identifier of an existing dialog, the dialog MUST be transitioned to the "confirmed" state, and the route set for the dialog MUST be recomputed based on the 2xx response using the procedures of Section 12.2.1.2. Otherwise, a new dialog in the "confirmed" state MUST be constructed using the procedures of Section 12.1.2. In context, you'll see the "existing dialog" above is an "early dialog". > > > > Should there be a mandate that 1xx and 2xx response carry the same record-route headers? You would assume that this happens naturally at the UAS, but proxies may play around with the record-route headers. > > > > - In the NOTIFY problem below, the NOTIFY establishes the dialog, but does not carry record-route headers. If the same assumption is made as above, the record-route headers appearing in the 200 response to the SUBSCRIBE are ignored since the dialog is in established state. Isn't this a problem? the route-set is lost. > > > > I appreciate some clarifications. > > > > Regards, > > Hisham > > > > > > > -----Original Message----- > > > From: ext hisham.khartabil@nokia.com > > > [mailto:hisham.khartabil@nokia.com] > > > Sent: Wednesday, March 12, 2003 5:37 PM > > > To: sip@ietf.org > > > Subject: [Sip] NOTIFY establishes a dialog > > > > > > > > > In RFC3265, it is mentioned that NOTIFY can certainly > > > establish a dialog if it arrives before the 200 of a > > > SUBSCRIBE. What happens when the 200 for the SUBSCRIBE now > > > arrives with record-route headers? Does the route-set get > > > updated? (keeping in mind that the dialog is now in the > > > established state). > > > > > > Regards, > > > Hisham > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > Use sipping@ietf.org for new developments on the application of sip > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Thu Mar 20 11:46:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24143 for ; Thu, 20 Mar 2003 11:46:59 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2KH4ui04410 for sip-archive@odin.ietf.org; Thu, 20 Mar 2003 12:04:56 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2KH4DO04371; Thu, 20 Mar 2003 12:04:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2KGxKO04086 for ; Thu, 20 Mar 2003 11:59:20 -0500 Received: from dyn-tx-arch-crash.dfw.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24016 for ; Thu, 20 Mar 2003 11:40:53 -0500 (EST) Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h2KGgp909020; Thu, 20 Mar 2003 10:42:51 -0600 Subject: RE: [Sip] NOTIFY establishes a dialog From: Robert Sparks To: Arunachalam Venkatraman Cc: sip@ietf.org In-Reply-To: References: Content-Type: text/plain Message-Id: <1048178529.958.10.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 20 Mar 2003 08:42:10 -0800 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit The only think I can think of this morning (IETF weeks are always brutal) is that as the text is currently written, the proxies can rewrite the record-route header field values as the responses propogate back (to deal with things like multiple interfaces or transport protocol changes that can't be dealt with via SRV). Its possible for a proxy to provide a URI with different parameters on the provisional and final response (to indicate to itself whether its dealing with an early or confirmed dialog perhaps). Now, subsequent conversations indicate that we probably want to discourage this rewriting in favor of the double-record-route solution so that the RR header field in a response can be signed by the responding endpoint. The quoted text below would become irrelevant if we made it illegal for proxies to rewrite RR header field values. RjS On Thu, 2003-03-20 at 07:54, Arunachalam Venkatraman wrote: > Robert > Can you explain the reasoning behind the section from RFC3261 that you have > quoted below? > I would think the Record-Route headers on the 1xx and 200 will be identical > since the responses would traverse (backwards) the same path that the INVITE > took, using the same VIA set. > Why should one recompute the Route Set? The only thing that may change is > the Contact, isn't it? > Venkat > > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Robert > Sparks > Sent: Wednesday, March 19, 2003 11:55 PM > To: Ganesh Sivaraman; hisham.khartabil@nokia.com > Cc: sip@ietf.org > Subject: RE: [Sip] NOTIFY establishes a dialog > > > response to one of the questions inline: > > On Wed, 2003-03-19 at 20:55, Ganesh Sivaraman wrote: > > Hi Hisham, > > I'd posted the same question about setting dialog-state (route-set > > etc.) and I got the following response: > > > 9.html> > > > > It says: > > "RFC 3265 augments 3261, in that the dialog in this case can be created > > either by a response to SUBSCRIBE or by NOTIFY". > > > > So that would mean that the route-set could be constructed with > > Route-headers (present in NOTIFY) also. Is this a correct assumption? > > > > A word from the authors of the RFC on this would help bring more > > clarity. > > > > Regards > > Ganesh > > > > On Thu, 2003-03-20 at 04:17, hisham.khartabil@nokia.com wrote: > > > I have a few related questions/comments: > > > > > > - A 180 response to a request (like INVITE) establishes a dialog. This > 180 response carries record-route headers and therefore sets the route-set. > The 200 response to the request might also carry record-route headers. The > dialog transitions to confirmed state, but I assume the route-set does not > get updated using the record-route headers in the 200 response since the > dialog is established already. Is this a correct assumption? should the UAS > send record-route headers at all in the 200 if it sent a 1xx already? > > >From rfc3261 page 82: > > If the dialog identifier in the 2xx response matches the dialog > identifier of an existing dialog, the dialog MUST be transitioned to > the "confirmed" state, and the route set for the dialog MUST be > recomputed based on the 2xx response using the procedures of Section > 12.2.1.2. Otherwise, a new dialog in the "confirmed" state MUST be > constructed using the procedures of Section 12.1.2. > > In context, you'll see the "existing dialog" above is an "early dialog". > > > > > > > Should there be a mandate that 1xx and 2xx response carry the same > record-route headers? You would assume that this happens naturally at the > UAS, but proxies may play around with the record-route headers. > > > > > > - In the NOTIFY problem below, the NOTIFY establishes the dialog, but > does not carry record-route headers. If the same assumption is made as > above, the record-route headers appearing in the 200 response to the > SUBSCRIBE are ignored since the dialog is in established state. Isn't this a > problem? the route-set is lost. > > > > > > I appreciate some clarifications. > > > > > > Regards, > > > Hisham > > > > > > > > > > -----Original Message----- > > > > From: ext hisham.khartabil@nokia.com > > > > [mailto:hisham.khartabil@nokia.com] > > > > Sent: Wednesday, March 12, 2003 5:37 PM > > > > To: sip@ietf.org > > > > Subject: [Sip] NOTIFY establishes a dialog > > > > > > > > > > > > In RFC3265, it is mentioned that NOTIFY can certainly > > > > establish a dialog if it arrives before the 200 of a > > > > SUBSCRIBE. What happens when the 200 for the SUBSCRIBE now > > > > arrives with record-route headers? Does the route-set get > > > > updated? (keeping in mind that the dialog is now in the > > > > established state). > > > > > > > > Regards, > > > > Hisham > > > > _______________________________________________ > > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > > This list is for NEW development of the core SIP Protocol > > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > > Use sipping@ietf.org for new developments on the application of sip > > > > > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Thu Mar 20 12:40:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26666 for ; Thu, 20 Mar 2003 12:40:29 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2KHwQA09571 for sip-archive@odin.ietf.org; Thu, 20 Mar 2003 12:58:26 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2KHvtO09459; Thu, 20 Mar 2003 12:57:55 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2KHeoO08769 for ; Thu, 20 Mar 2003 12:40:50 -0500 Received: from lohi.eng.song.fi (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25815 for ; Thu, 20 Mar 2003 12:22:22 -0500 (EST) Received: from jh by lohi.eng.song.fi with local (Exim 3.36 #1 (Debian)) id 18w3mJ-0002kh-00; Thu, 20 Mar 2003 19:24:31 +0200 From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15993.63823.403073.205367@lohi.eng.song.fi> Date: Thu, 20 Mar 2003 19:24:31 +0200 To: Robert Sparks Cc: Arunachalam Venkatraman , sip@ietf.org Subject: RE: [Sip] NOTIFY establishes a dialog In-Reply-To: <1048178529.958.10.camel@RjS.localdomain> References: <1048178529.958.10.camel@RjS.localdomain> X-Mailer: VM 6.97 under Emacs 20.7.2 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Robert Sparks writes: > Now, subsequent conversations indicate that we probably want to > discourage this rewriting in favor of the double-record-route > solution so that the RR header field in a response can be signed > by the responding endpoint. The quoted text below would become > irrelevant if we made it illegal for proxies to rewrite RR header > field values. at least proxys should be allowed to add parameters to record route/route headers. by the way, i think it is a big mistake that the current sip rfc doesn't allow a re-invite to include a new record route. consider the case where a call originates in a mobile network and then roams to wlan, for example. it would be really stupid if the subsequent messages of the dialog would need to go via the proxies of the mobile network. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Thu Mar 20 15:06:43 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03080 for ; Thu, 20 Mar 2003 15:06:43 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2KKOgT21941 for sip-archive@odin.ietf.org; Thu, 20 Mar 2003 15:24:42 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2KKNPO21809; Thu, 20 Mar 2003 15:23:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2KKHdO21570 for ; Thu, 20 Mar 2003 15:17:39 -0500 Received: from f1ee40-19.idc1.level3.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02256 for ; Thu, 20 Mar 2003 14:59:08 -0500 (EST) Received: from idc1exc0001.corp.global.level3.com (localhost [127.0.0.1]) by f1ee40-19.idc1.level3.com (8.8.8+Sun/8.8.8) with SMTP id UAA23840 for ; Thu, 20 Mar 2003 20:01:22 GMT Received: from idc1exc0004.corp.global.level3.com ([10.1.6.220]) by idc1exc0001.corp.global.level3.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 20 Mar 2003 13:01:22 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6334.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2EF1B.7A805C61" Date: Thu, 20 Mar 2003 13:01:21 -0700 Message-ID: <0DF3CAB7F668E649A521E5E263EDD5F954DF39@idc1exc0004.corp.global.level3.com> Thread-Topic: Cancel with a message body Thread-Index: AcLvG3qMLPt2iHJMRJK1XE3OhWOcHw== From: "Everist, Giles" To: X-OriginalArrivalTime: 20 Mar 2003 20:01:22.0125 (UTC) FILETIME=[7AAF27D0:01C2EF1B] Subject: [Sip] Cancel with a message body Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C2EF1B.7A805C61 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Can a Cancel have a message body, and if so does a stateful proxy have the same responsibility to maintain that message body in a generated Cancel request as with other messages? Also, is the proxy required to maintain ALL headers, such as a "Reason" header in the original Cancel request? Thanks for the help. =20 Giles ------_=_NextPart_001_01C2EF1B.7A805C61 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Can a Cancel have a message body, and if so does a = stateful proxy have the same responsibility to maintain that message body in a = generated Cancel request as with other messages?  Also, is the proxy required to maintain ALL headers, such as a = “Reason” header in the original Cancel request?  Thanks for the help.

 

Giles

=00 ------_=_NextPart_001_01C2EF1B.7A805C61-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Fri Mar 21 00:53:08 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22678 for ; Fri, 21 Mar 2003 00:53:08 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2L6BK132107 for sip-archive@odin.ietf.org; Fri, 21 Mar 2003 01:11:20 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2L69lO31958; Fri, 21 Mar 2003 01:09:47 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2L649O31017 for ; Fri, 21 Mar 2003 01:04:09 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22511 for ; Fri, 21 Mar 2003 00:45:26 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by albatross.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2L5lebh001547; Fri, 21 Mar 2003 06:47:40 +0100 (MET) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id HH5MNJT9; Fri, 21 Mar 2003 06:47:40 +0100 Received: from lmf.ericsson.se (vrrch1-177027.am.ericsson.se [138.85.177.27]) by hendrix.lmf.ericsson.se (8.12.8/8.12.8/lmf-2.1-jcs) with ESMTP id h2L5lcEq000224; Fri, 21 Mar 2003 07:47:39 +0200 (EET) Message-ID: <3E7AA7E8.36CC5DEC@lmf.ericsson.se> Date: Fri, 21 Mar 2003 07:49:29 +0200 X-Sybari-Trust: e02375fd d6a25af5 ae26be38 00000138 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Robert Sparks CC: sip@ietf.org Subject: Re: [Sip] NOTIFY establishes a dialog References: <2038BCC78B1AD641891A0D1AE133DBB7FE73E7@esebe019.ntc.nokia.com> <1048136137.18805.25.camel@Ganesh> <1048139722.954.6.camel@RjS.localdomain> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Robert, > >From rfc3261 page 82: > > If the dialog identifier in the 2xx response matches the dialog > identifier of an existing dialog, the dialog MUST be transitioned to > the "confirmed" state, and the route set for the dialog MUST be > recomputed based on the 2xx response using the procedures of Section > 12.2.1.2. Otherwise, a new dialog in the "confirmed" state MUST be > constructed using the procedures of Section 12.1.2. > > In context, you'll see the "existing dialog" above is an "early dialog". Chapter 4 in RFC3262 says: "The UAC MAY acknowledge reliable provisional responses received after the final response or MAY discard them." Now, IF the UAC chooses to acknowledge reliable provisional responses after the final response is received, which route set should it use for the PRACK? The route set it used for the other PRACKs in the "early state", or the possible new route set is has for the "confirmed state"? Regards, Christer Holmberg Ericsson Finland _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Fri Mar 21 01:12:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23066 for ; Fri, 21 Mar 2003 01:12:51 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2L6V4X00432 for sip-archive@odin.ietf.org; Fri, 21 Mar 2003 01:31:04 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2L6TQO32736; Fri, 21 Mar 2003 01:29:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2L6QwO32644 for ; Fri, 21 Mar 2003 01:26:58 -0500 Received: from dyn-tx-arch-crash.dfw.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22961 for ; Fri, 21 Mar 2003 01:08:14 -0500 (EST) Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h2L6AQ920810; Fri, 21 Mar 2003 00:10:26 -0600 Subject: Re: [Sip] NOTIFY establishes a dialog From: Robert Sparks To: Christer Holmberg Cc: sip@ietf.org In-Reply-To: <3E7AA7E8.36CC5DEC@lmf.ericsson.se> References: <2038BCC78B1AD641891A0D1AE133DBB7FE73E7@esebe019.ntc.nokia.com> <1048136137.18805.25.camel@Ganesh> <1048139722.954.6.camel@RjS.localdomain> <3E7AA7E8.36CC5DEC@lmf.ericsson.se> Content-Type: text/plain Message-Id: <1048226978.2030.20.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 20 Mar 2003 22:09:38 -0800 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Nice question. >From a constructionist view, the PRACK is clearly associated with the early dialog and should use the early dialog route set. From a practical point of view, using either the early or confirmed route set gets the PRACK to the place that needs it, so what does it matter? (Can you construct a case where a proxy would care?) I think, though, that the idea that the early and established route sets can be different is just an artifact of the way we defined record-route rewriting instead of a feature we really intended to engineer. (If someone knows differently, please speak up). The double-record-route solution for those cases where rewriting is necessary would allow the RR field in a response to be signed. That would _prevent_ the early and confirmed route sets from being different. I suspect that's a more desired behavior. So to answer your question more succinctly: - I don't think it matters which you use - The potential difference should go away anyhow RjS On Thu, 2003-03-20 at 21:49, Christer Holmberg wrote: > Hi Robert, > > > >From rfc3261 page 82: > > > > If the dialog identifier in the 2xx response matches the dialog > > identifier of an existing dialog, the dialog MUST be transitioned to > > the "confirmed" state, and the route set for the dialog MUST be > > recomputed based on the 2xx response using the procedures of Section > > 12.2.1.2. Otherwise, a new dialog in the "confirmed" state MUST be > > constructed using the procedures of Section 12.1.2. > > > > In context, you'll see the "existing dialog" above is an "early dialog". > > Chapter 4 in RFC3262 says: > > "The UAC MAY acknowledge reliable provisional responses received after > the final response or MAY discard them." > > Now, IF the UAC chooses to acknowledge reliable provisional responses after the final response is received, which route set should it use for the PRACK? The route set it used for the other PRACKs in the "early state", or the possible new route set is has for the "confirmed state"? > > Regards, > > Christer Holmberg > Ericsson Finland _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Fri Mar 21 06:37:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10778 for ; Fri, 21 Mar 2003 06:37:14 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2LBtXA31074 for sip-archive@odin.ietf.org; Fri, 21 Mar 2003 06:55:33 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LBt1O31054; Fri, 21 Mar 2003 06:55:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LBlNO30775 for ; Fri, 21 Mar 2003 06:47:23 -0500 Received: from dns1 (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10536 for ; Fri, 21 Mar 2003 06:28:32 -0500 (EST) Received: from [61.11.77.97] by dns1 (ArGoSoft Mail Server Pro for WinNT/2000/XP, Version 1.8 (1.8.2.5)); Fri, 21 Mar 2003 03:31:31 -0800 From: sipdev To: "sip@ietf.org" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <2wlmebsstdj5nq3.210320030331@dns1> Date: Fri, 21 Mar 2003 03:31:31 -0800 Content-Transfer-Encoding: 7bit Subject: [Sip] (no subject) Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit hai I am new to ser and sip. I would like to know how to connect ser and UA. I have Red Hat Linux V. 8 and Windows NT and For UA I have Xphone from xten Thankz Keerthi _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Fri Mar 21 06:44:06 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10845 for ; Fri, 21 Mar 2003 06:44:06 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2LC2PF31360 for sip-archive@odin.ietf.org; Fri, 21 Mar 2003 07:02:25 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LC1uO31331; Fri, 21 Mar 2003 07:01:56 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LBoDO30922 for ; Fri, 21 Mar 2003 06:50:13 -0500 Received: from beamer.mchh.siemens.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10585 for ; Fri, 21 Mar 2003 06:31:22 -0500 (EST) Received: from moody.mchh.siemens.de ([139.21.205.85]) by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id MAA06376; Fri, 21 Mar 2003 12:33:35 +0100 (MET) Received: from mchh247e.demchh201e.icn.siemens.de (mchh247e.mchh.siemens.de [139.21.200.57]) by moody.mchh.siemens.de (8.9.3/8.9.1) with ESMTP id MAA17443; Fri, 21 Mar 2003 12:33:34 +0100 (MET) Received: by mchh247e.mchh.siemens.de with Internet Mail Service (5.5.2656.59) id ; Fri, 21 Mar 2003 12:33:17 +0100 Message-ID: <15A0F4D7BF4DD411BD4C0008C71E2F28019D2D70@mchh233e.mchh.siemens.de> From: Milinski Alexander To: "'Kevin Lingle'" , Jonathan Rosenberg Cc: sip@ietf.org, Dave Walker Subject: RE: [Sip] I-D ACTION:draft-ietf-sip-mib-05.txt Date: Fri, 21 Mar 2003 12:33:16 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="ISO-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Hi Kevin and Janathan, the concern raised by Jonathan seems very valid. Like Jonathan I do not think that it is benefitial to make transient information (like details of each ongoing dialog in the SipTransactionEntry) available via the SIP MIB. Kind regards, Alexander Alexander Milinski Siemens mobile -----Original Message----- From: Kevin Lingle [mailto:klingle@cisco.com] Sent: Wednesday, March 19, 2003 4:40 PM To: Jonathan Rosenberg Cc: sip@ietf.org; Dave Walker Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-mib-05.txt Jonathan Rosenberg wrote: > > Kevin Lingle wrote: > > >>I have begun to look at the mib a bit, and I am a bit concerned that > >>there is far too much information exposed, in terms of statistics, at > >>least. I have to apologize for raising this so late in the game, but it > >>is only recently that my day job has brought me into OAMP areas. > > > > > > not sure if the above reference to statistics is directly related > > to your comment on sipTransactionTable below or not. > > Yes. > > > if not, are there > > other statistics that you feel fall into the category or > > exposing far too much information? > > I want to look some more and provide some additional comments. that would be great. > > > > > > >>One item that struck me as particularly demanding on an implementation > >>is the sipTransactionTable. There is a huge amount of work in > >>maintaining this table. I really doubt people will want to implement it. > > > > > > i had similar feedback from others when support of the sipTransactionTable > > was being considered by a project. the effort involved in supporting > > the table was a problem. > > > > we can focus some discussion on the viability of the table during wg last call. > > Well, discussion can happen any time. Its happening now, in this email > thread. I dont know what else you are expecting. sorry. didn't mean to imply what came across. we can definitely discuss it now. i'm just not used to actually having active discussion of the mib. i'm used to getting one or two sporatic comments and only having focused discussion during last call - when someone is forced to review the mib ;) > I don't think the table > is viable. You had similar feedback. Seems like a clear cut resolution > to me. not that i don't take your point of view as very significant, i do. i was hoping that others might concur before we decide to remove the table. the table has been in every revision of the mib, so it has been reviewed multiple times by multiple people... no one - until now has recommended it come out. i guess i had taken that as acceptance of it's potential usefulness to someone. my case of one project finding it questionable does not necessarily make a case for it's removal. we determined that support was feasible but not all that useful for our platform. implementation experience with a mib usually decides such things and we don't have much (any?) feedback in that area (not likely to until the mibs are in an rfc). still, if we can resolve the question of usefulness now it would be better than to have to revise the mib (ie, rfc) and deprecate objects found - through implementation experience - to be useless. > > > i'd rather do that than to yank the table w/out further discussion. > > *This* is the discussion. agreed. > > > at the very least, we can definitely make the table optional. > > right now it appears to be in a mandatory group - which seem wrong to me anyway. > > Mandatory is definitely wrong. I am not even sure optional is useful. > > So - here is the question. What is the bar for putting something in the > MIB? At one extreme, every piece of state managed by a server could be > in the mib. At the other extreme, there is nothing, or a single summary > statistic. I think a reasonable bar, is that there should be clear value > in monitoring that information, from the perspective of fault and > performance management in particular. If you cannot demonstrate such a > use, it should be out. > > I cannot think of a reason that I would want, from an operations center, > to monitor the current set of transactions held in the system. Thus, I > think it should be out. it's hard for me to justify or defend the existence of this table as i was not the original author of it. but for the sake of discussion... is there no value from a troubleshooting perspective? you mentioned that this information is likely logged for offline analysis - not real-time. are transactions generally occuring too fast for real-time analysis to be of worth? it would seem to me that unless you know specifically which transactions are of interest to you, it would be hard to use this table for anything. the table is defintely not a logging mechanism as transactions will not persist for any historically significant time. from a performance mgmt point of view... could the increase in entries in this table be used to gain insight into congestion in this or other parts of the sip network? even if that were the case, the simple sipCurrentTransactions gauge object would provide similar insight (to congestion at least). perhaps the to/from details in the table would lend some more insight to problems elsewhere in the network? i'm not sure. dave walker was the original author of this table, so maybe he can offer some insight. dave? i did find one old comment related to this table squirreled away in some old emails.... Kurt Robohm wrote: > > sipCurrentTransacations Does this reflect number of > calls in progress? > Intent of objects in table to > sipTransactionTable provide real time info on > number of calls being handled > real time? Dave Walker responded: > Transactions aren't calls. The intent, as mentioned in Adelaide, > is to evolve the transaction table to a call leg table (probably > for UAs only). This hasn't been resolved yet, so no real changes > were made. i can't find any further discussion by dave (or others) in subsequent revisions of the draft to work out any further evolution of this table. only minor comments related to the table - none questioning its existence. dave's involvement in the last couple of revisions of the draft have been nil. so perhaps the table is an articfact of an idea that was not fully conceived or fleshed out. that would lend itself to removal imo. kevin > > Is not our aim to take things out of protocols until we can't take out > any more, rather than the other way around? > > -Jonathan R. > > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Kevin R. Lingle 919.392.2029 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Fri Mar 21 12:29:55 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19614 for ; Fri, 21 Mar 2003 12:29:54 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2LHmLM22018 for sip-archive@odin.ietf.org; Fri, 21 Mar 2003 12:48:21 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LHlMO21878; Fri, 21 Mar 2003 12:47:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LHXfO20626 for ; Fri, 21 Mar 2003 12:33:41 -0500 Received: from rtp-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19243 for ; Fri, 21 Mar 2003 12:14:43 -0500 (EST) Received: from dingdong.cisco.com (IDENT:mirapoint@dingdong.cisco.com [64.102.17.16]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2LHGkiH027417; Fri, 21 Mar 2003 12:16:46 -0500 (EST) Received: from cisco.com (klingle-ultra.cisco.com [64.102.93.47]) by dingdong.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ABX18047; Fri, 21 Mar 2003 12:16:45 -0500 (EST) Message-ID: <3E7B48FD.4A1C1EAB@cisco.com> Date: Fri, 21 Mar 2003 12:16:45 -0500 From: Kevin Lingle X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: sshetti@hss.hns.com CC: Jonathan Rosenberg , sip@ietf.org, Dave Walker Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-mib-05.txt References: <65256CEF.001BC43B.00@sampark.hss.hns.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit thanks for all of the input wrt sipTransactionTable. consider the table removed from the mib. i plan on keeping the sipCurrentTransactions gauge object but will make it part of an optional group. shrinivas, thanks for you other comments. i'll go through them soon. kevin sshetti@hss.hns.com wrote: > > We too have sip-mib implementation in our product. > Following is my view with respect to sipTransactionTable: > > 1. Maintaining this table info in the system is not > 'simple and straight forward'. > Reason: Data involved are very volatile. > Moreover it requires indexing the transactions which > themselves are volatile (destroyed any time). > > 2. This information is usually obtained (if et-all obtained!) > will be via GET-BULK operation. To support GET-BULK to > retrieve information specific to all transactions > has momentory performance impact on the Server. > There are issues of thread-safety between GET-BULK > and the transaction handling operation. > > 3. Same information can be obtained either through > protocol trace logs or CDR (call detail records). > > I feel sip-mib should not have tables involving volatile data. > > I also feel sipCurrentTransTable is not useful. > May be TRAP objects based on sipCurrentTransTable, will be > more useful to SNMP admin. > > I think sip-mib has captured very elaborately on following things. > 1. Server Administration/Configuration > 2. User data management > 3. Statistics > I really appreciate the above factor. > > I have some comments on following MIB fields, please > clarify them as my understanding may differ from the > auther's of sip-mib. > > 1. "sipMaxSessions" of SipCommonCfgEntry: > This is a READ-ONLY property supplied by the > SIP-ENTITY. As per the definition the entity > has to determine what is the maximum load it > can handle. > > Again, the above factor depends on the > hardware/software configuration of the deployment > platform. Do we expect for instance a SIP-Proxy > to run some algorithm/load itself to find out > this value? > > I feel this field may not be useful. > > 2. "sipTransportSnd" of SipPortEntry: I donot > understand how this field is utilized in SIP, > specific to a port number. > > "sipTransportRcv" can be understood as for > associated port number the SIP entity will > receive message for TRANSPORTS that are > enabled in this field. > > 3. "sipPgpVersion" of SipServerCfgEntry, > "sipPgpPrivateKey" of SipProxyCfgEntry: > PGP is deprecated in SIP. Can these be removed? > There may be more things specific to PGP. > > 4. "sipServerRespectUAAction" of SipServerCfgEntry: > This mentions action parameter specific operation > in the proxy which is deprecated in SIP. > Can we deprecate here also? > > 5. "sipRegMaxUsers" of "SipRegCfgEntry": > This is a READ-ONLY field which is supposed > to be given out by REGISTRAR as what is the > number of users does it support. > > Again, what is the criteria with which registrar > arrives at this data. This data again depends on > deployment platform such as capacity of the > database etc. This data too may not be useful > to administrator. This value is either known > to the admin or enforced by admin on REGISTRAR. > Therefore keeping it as READ-ONLY has no purpose. > > 6. "sipContactAction" of SipContactEntry: > Again deprecated by SIP. Can we deprecate here too? > > 7. "sipContactRetryAfter" of SipContactEntry: > Again deprecated by SIP. Can we deprecate here too? > > 8. Transaction timer specific configuration are based > on pre-bis05 drafts. They have to be updated > according to latest RFC. I think action-item is already > initiated for post mib-05 drafts. > > Thanks and Regards, > Shrinivas Shetti > > Kevin Lingle on 03/19/2003 09:10:17 PM > > To: Jonathan Rosenberg > cc: sip@ietf.org, Dave Walker (bcc: Shrinivas > Shetti/HSSBLR) > > Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-mib-05.txt > > Jonathan Rosenberg wrote: > > > > Kevin Lingle wrote: > > > > >>I have begun to look at the mib a bit, and I am a bit concerned that > > >>there is far too much information exposed, in terms of statistics, at > > >>least. I have to apologize for raising this so late in the game, but it > > >>is only recently that my day job has brought me into OAMP areas. > > > > > > > > > not sure if the above reference to statistics is directly related > > > to your comment on sipTransactionTable below or not. > > > > Yes. > > > > > if not, are there > > > other statistics that you feel fall into the category or > > > exposing far too much information? > > > > I want to look some more and provide some additional comments. > > that would be great. > > > > > > > > > > > >>One item that struck me as particularly demanding on an implementation > > >>is the sipTransactionTable. There is a huge amount of work in > > >>maintaining this table. I really doubt people will want to implement > it. > > > > > > > > > i had similar feedback from others when support of the > sipTransactionTable > > > was being considered by a project. the effort involved in supporting > > > the table was a problem. > > > > > > we can focus some discussion on the viability of the table during wg > last call. > > > > Well, discussion can happen any time. Its happening now, in this email > > thread. I dont know what else you are expecting. > > sorry. didn't mean to imply what came across. we can definitely discuss > it now. i'm just not used to actually having active discussion of the mib. > i'm used to getting one or two sporatic comments and only having focused > discussion during last call - when someone is forced to review the mib ;) > > > I don't think the table > > is viable. You had similar feedback. Seems like a clear cut resolution > > to me. > > not that i don't take your point of view as very significant, i do. > i was hoping that others might concur before we decide to remove the table. > the table has been in every revision of the mib, so it has been reviewed > multiple times by multiple people... no one - until now has recommended it > come out. i guess i had taken that as acceptance of it's potential > usefulness > to someone. my case of one project finding it questionable does not > necessarily > make a case for it's removal. we determined that support was feasible but > not all that useful for our platform. > > implementation experience with a mib usually decides such things and we > don't > have much (any?) feedback in that area (not likely to until the mibs are in > an > rfc). still, if we can resolve the question of usefulness now it would be > better than > to have to revise the mib (ie, rfc) and deprecate objects found - through > implementation experience - to be useless. > > > > > > i'd rather do that than to yank the table w/out further discussion. > > > > *This* is the discussion. > > agreed. > > > > > > at the very least, we can definitely make the table optional. > > > right now it appears to be in a mandatory group - which seem wrong to > me anyway. > > > > Mandatory is definitely wrong. I am not even sure optional is useful. > > > > So - here is the question. What is the bar for putting something in the > > MIB? At one extreme, every piece of state managed by a server could be > > in the mib. At the other extreme, there is nothing, or a single summary > > statistic. I think a reasonable bar, is that there should be clear value > > in monitoring that information, from the perspective of fault and > > performance management in particular. If you cannot demonstrate such a > > use, it should be out. > > > > I cannot think of a reason that I would want, from an operations center, > > to monitor the current set of transactions held in the system. Thus, I > > think it should be out. > > it's hard for me to justify or defend the existence of this table as i > was not the original author of it. but for the sake of discussion... > > is there no value from a troubleshooting perspective? you mentioned that > this information is likely logged for offline analysis - not real-time. > are transactions generally occuring too fast for real-time analysis to > be of worth? it would seem to me that unless you know specifically which > transactions are of interest to you, it would be hard to use this table > for anything. the table is defintely not a logging mechanism as > transactions > will not persist for any historically significant time. > > from a performance mgmt point of view... > could the increase in entries in this table be used to gain insight into > congestion in this or other parts of the sip network? even if that were > the case, the simple sipCurrentTransactions gauge object would provide > similar insight (to congestion at least). perhaps the to/from details > in the table would lend some more insight to problems elsewhere in the > network? i'm not sure. > > dave walker was the original author of this table, so maybe > he can offer some insight. dave? > i did find one old comment related to this table squirreled away in some > old emails.... > > Kurt Robohm wrote: > > > > sipCurrentTransacations Does this reflect number of > > calls in progress? > > Intent of objects in table to > > sipTransactionTable provide real time info on > > number of calls being handled > > real time? > > Dave Walker responded: > > Transactions aren't calls. The intent, as mentioned in Adelaide, > > is to evolve the transaction table to a call leg table (probably > > for UAs only). This hasn't been resolved yet, so no real changes > > were made. > > i can't find any further discussion by dave (or others) in subsequent > revisions of the draft to work out any further evolution of this table. > only minor comments related to the table - none questioning its existence. > dave's involvement in the last couple of revisions of the draft have been > nil. > so perhaps the table is an articfact of an idea that was not fully > conceived or fleshed out. that would lend itself to removal imo. > > kevin > > > > Is not our aim to take things out of protocols until we can't take out > > any more, rather than the other way around? > > > > -Jonathan R. > > > > -- > > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > > Chief Scientist First Floor > > dynamicsoft East Hanover, NJ 07936 > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > http://www.jdrosen.net PHONE: (973) 952-5000 > > http://www.dynamicsoft.com > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > -- > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Kevin R. Lingle 919.392.2029 > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Kevin R. Lingle 919.392.2029 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Fri Mar 21 22:10:00 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06217 for ; Fri, 21 Mar 2003 22:09:59 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2M3Sbf30753 for sip-archive@odin.ietf.org; Fri, 21 Mar 2003 22:28:37 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2M3S5O30729; Fri, 21 Mar 2003 22:28:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2M3KcO30538 for ; Fri, 21 Mar 2003 22:20:38 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06121 for ; Fri, 21 Mar 2003 22:01:30 -0500 (EST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.5/Switch-2.2.5) with ESMTP id h2M37Qu05257 for ; Sat, 22 Mar 2003 05:07:26 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Sat, 22 Mar 2003 05:03:45 +0200 Received: from mgw.research.nokia.com ([172.21.33.76]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Sat, 22 Mar 2003 05:03:44 +0200 Received: from localhost.localdomain (nokesa195117.europe.nokia.com [172.21.195.117]) by mgw.research.nokia.com (8.9.3/8.9.3) with ESMTP id FAA25194; Sat, 22 Mar 2003 05:03:37 +0200 (EET) Received: from localhost.localdomain (localhost [127.0.0.1]) by localhost.localdomain (8.12.8/8.12.5) with ESMTP id h2M337Rt008275; Sat, 22 Mar 2003 05:03:10 +0200 Received: (from ppessi@localhost) by localhost.localdomain (8.12.8/8.12.5/Submit) id h2M1s7lW007781; Sat, 22 Mar 2003 03:54:07 +0200 X-Authentication-Warning: localhost.localdomain: ppessi set sender to Pekka.Pessi@nokia.com using -f To: Giles , Subject: Re: [Sip] Cancel with a message body X-face: #V(jdpv[lI!TNUU=2*oh:="#suS*ponXW"yr6G;~L}uZ\JfD\"IG#G{j`hZI;=DmT\H pfDMyJ`i=:M;BM3R.`[>P^ER8+]i From: Pekka Pessi In-Reply-To: <0DF3CAB7F668E649A521E5E263EDD5F954DF39@idc1exc0004.corp.global.level3.com> (Everist, Giles's message of "Thu, 20 Mar 2003 13:01:21 -0700") User-Agent: Gnus/5.09001 (Oort Gnus v0.10) XEmacs/21.4 (Honest Recruiter, i386-redhat-linux) References: <0DF3CAB7F668E649A521E5E263EDD5F954DF39@idc1exc0004.corp.global.level3.com> Date: Sat, 22 Mar 2003 03:54:07 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-OriginalArrivalTime: 22 Mar 2003 03:03:44.0380 (UTC) FILETIME=[A64223C0:01C2F01F] Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Everist, Giles writes: > Kewl. >Can a Cancel have a message body, and if so does a stateful proxy have >the same responsibility to maintain that message body in a generated >Cancel request as with other messages? Also, is the proxy required to >maintain ALL headers, such as a "Reason" header in the original Cancel >request? Thanks for the help. CANCEL is a hop-by-hop request, so stateful proxies do not forward it. No message-body or headers get forwarded. Pekka _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Sat Mar 22 14:55:46 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02538 for ; Sat, 22 Mar 2003 14:55:46 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2MKEjP00626 for sip-archive@odin.ietf.org; Sat, 22 Mar 2003 15:14:45 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2MKE0O00606; Sat, 22 Mar 2003 15:14:00 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2MK8eO00419 for ; Sat, 22 Mar 2003 15:08:40 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02491 for ; Sat, 22 Mar 2003 14:49:10 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by penguin.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2MJpOHQ019192; Sat, 22 Mar 2003 20:51:24 +0100 (MET) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id HKFW8D95; Sat, 22 Mar 2003 20:51:22 +0100 Received: from lmf.ericsson.se (rmt160223.am.ericsson.se [138.85.160.223]) by hendrix.lmf.ericsson.se (8.12.8/8.12.8/lmf-2.1-jcs) with ESMTP id h2MJpJEq021019; Sat, 22 Mar 2003 21:51:20 +0200 (EET) Message-ID: <3E7CBF32.3745B0DE@lmf.ericsson.se> Date: Sat, 22 Mar 2003 21:53:23 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Robert Sparks CC: sip@ietf.org Subject: Re: [Sip] NOTIFY establishes a dialog References: <2038BCC78B1AD641891A0D1AE133DBB7FE73E7@esebe019.ntc.nokia.com> <1048136137.18805.25.camel@Ganesh> <1048139722.954.6.camel@RjS.localdomain> <3E7AA7E8.36CC5DEC@lmf.ericsson.se> <1048226978.2030.20.camel@RjS.localdomain> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Robert, > From a constructionist view, the PRACK is clearly associated with the > early dialog and should use the early dialog route set. From a practical > point of view, using either the early or confirmed route set gets the > PRACK to the place that needs it, so what does it matter? (Can you > construct a case where a proxy would care?) First, if we use connection protocols, with or without security (TCP, TLS etc), nodes may have to establish two connections (if the next hop is different in the early- and confirmed route sets). This affects, of course, both UAs and proxies. Second, since we are not allowed to change the route once the dialog has been "confirmed", there may be proxies which checks the route for incoming request. And, those proxies may not know the semantics of PRACK, so they may think the request is for the confirmed dialog, and reject it because it tries to use another route. Third, this MAY also affect other early dialog requests (UPDATE, INFO), which due to race conditions are sent after the dialog has been confirmed. >From a proxy point of view, however, I guess this is not different from the PRACK case. Fourth, but this I haven't thought so much about yet, could this somehow affect the work on connection reuse? > I think, though, that the idea that the early and established route > sets can be different is just an artifact of the way we defined > record-route rewriting instead of a feature we really intended to > engineer. Personally I don't see any reason why it should be allowed in the first place. Because, we are NOT allowed to change the Contact header in 18x and 200 responses, are we? So, why should we be allowed to change Record-Route? Of course, IF someone has reasons why proxies should be involved only in the early state, or in the confirmed state, that is another issue, but in the case the question is if we should have a generic way of changing the route set - also after the dialog has been confirmed (Juha mentioned cases where such functionality could be useful). Regards, Christer Holmberg Ericsson Finland > (If someone knows differently, please speak up). The > double-record-route solution for those cases where rewriting > is necessary would allow the RR field in a response to be signed. > That would _prevent_ the early and confirmed route sets from being > different. I suspect that's a more desired behavior. > > So to answer your question more succinctly: > - I don't think it matters which you use > - The potential difference should go away anyhow > > RjS > > On Thu, 2003-03-20 at 21:49, Christer Holmberg wrote: > > Hi Robert, > > > > > >From rfc3261 page 82: > > > > > > If the dialog identifier in the 2xx response matches the dialog > > > identifier of an existing dialog, the dialog MUST be transitioned to > > > the "confirmed" state, and the route set for the dialog MUST be > > > recomputed based on the 2xx response using the procedures of Section > > > 12.2.1.2. Otherwise, a new dialog in the "confirmed" state MUST be > > > constructed using the procedures of Section 12.1.2. > > > > > > In context, you'll see the "existing dialog" above is an "early dialog". > > > > Chapter 4 in RFC3262 says: > > > > "The UAC MAY acknowledge reliable provisional responses received after > > the final response or MAY discard them." > > > > Now, IF the UAC chooses to acknowledge reliable provisional responses after the final response is received, which route set should it use for the PRACK? The route set it used for the other PRACKs in the "early state", or the possible new route set is has for the "confirmed state"? > > > > Regards, > > > > Christer Holmberg > > Ericsson Finland _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Sun Mar 23 08:26:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01430 for ; Sun, 23 Mar 2003 08:26:42 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2NDk1104996 for sip-archive@odin.ietf.org; Sun, 23 Mar 2003 08:46:01 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2NDjMO04962; Sun, 23 Mar 2003 08:45:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2NDfVO04899 for ; Sun, 23 Mar 2003 08:41:31 -0500 Received: from ierw.net.avaya.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01387 for ; Sun, 23 Mar 2003 08:21:40 -0500 (EST) Received: from ierw.net.avaya.com (localhost [127.0.0.1]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id IAA26707 for ; Sun, 23 Mar 2003 08:21:22 -0500 (EST) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id IAA26703 for ; Sun, 23 Mar 2003 08:21:20 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sip] I-D ACTION:draft-ietf-sip-mib-05.txt Date: Sun, 23 Mar 2003 15:23:56 +0200 Message-ID: Thread-Topic: [Sip] I-D ACTION:draft-ietf-sip-mib-05.txt Thread-Index: AcLuH4QLj76C3VE9TGGhK/0POAGlAADHtrwQ From: "Romascanu, Dan (Dan)" To: "Jonathan Rosenberg" , "Kevin Lingle" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2NDfVO04900 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit There is a delicate balance to be looked for here. I doubt that 'every piece pf state' is useful information, both on grounds of resources, as well quantity of information that needs to be processed. SNMP agents run on the same hosts that run protocols, and the management information carried from SNMP agents to SNMP clients (managers) competes for bandwidth with other data traffic. When designing a MIB one needs to take into account that in order for the MIB to be useful, it needs to run in the context of the host and application resources, and that the management traffic that is generated needs to be a reasonable fraction of the traffic of the protocol or application that is being managed. In the context of the current discussion it looks to me that large state or session tables should be avoided, with more compact indications, or threshold based alarms being put in place instead. Dan > So - here is the question. What is the bar for putting > something in the > MIB? At one extreme, every piece of state managed by a server > could be > in the mib. At the other extreme, there is nothing, or a > single summary > statistic. I think a reasonable bar, is that there should be > clear value > in monitoring that information, from the perspective of fault and > performance management in particular. If you cannot > demonstrate such a > use, it should be out. > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Mon Mar 24 02:04:16 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28755 for ; Mon, 24 Mar 2003 02:04:15 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2O7Nu708572 for sip-archive@odin.ietf.org; Mon, 24 Mar 2003 02:23:56 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2O7MlO08528; Mon, 24 Mar 2003 02:22:47 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2O7GCO07923 for ; Mon, 24 Mar 2003 02:16:12 -0500 Received: from sj-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24149 for ; Mon, 24 Mar 2003 01:56:00 -0500 (EST) 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.6/8.12.6) with ESMTP id h2O6va4c015047; Sun, 23 Mar 2003 22:57:36 -0800 (PST) Received: from cj14 (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with SMTP id ACO10804; Sun, 23 Mar 2003 22:57:35 -0800 (PST) From: "Cullen Jennings" To: "SVR Anand" , Cc: Subject: RE: Ri: [Sip] SIP proxy network Date: Sun, 23 Mar 2003 22:58:14 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <200303191033.QAA09756@eis.iisc.ernet.in> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit You might want to have a read of TRIP (RFC 3219) ftp://ftp.rfc-editor.org/in-notes/rfc3219.txt Is based off of BGP4 instead of OSPF. > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of SVR > Anand > Sent: Wednesday, March 19, 2003 2:34 AM > To: loretosa@vodafone.it > Cc: sip@ietf.org > Subject: Re: Ri: [Sip] SIP proxy network > > > The kind of information the proxies exchange should enable the UA > or local proxy > to dynamically locate and choose where to forward say,INVITE to. > Since the > information contained within proxies is at the application level > I am thinking if > an application level and perhaps text based routing protocol is necessary. > > > > > > I'm not sure about your question, > > are you asking about the possibility for UA or an > > inBound Proxy to choose the best way where send > > a message (like INVITE)? > > > > > > > Hi, > > > > > > Not sure if I am sending my mail to the proper mailing list. > > > > > > Just a wild thought. Can I think of network of SIP proxies > connected in some > > > way dynamically exchanging messages in order to assist in > forwarding of say, > > > INVITES to an appropriate proxy ? Just like OSPF for link > state information, > > > proxy network for say proxy configuration information exchange ? > > > > > > Please let me know if I am talking sense. > > > > > > Anand > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > Use sipping@ietf.org for new developments on the application of sip > > > > > > > Per registrarti gratuitamente a Vodafone Mail vai su www.190.it > > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Mon Mar 24 02:09:08 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03739 for ; Mon, 24 Mar 2003 02:09:08 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2O7SnR08997 for sip-archive@odin.ietf.org; Mon, 24 Mar 2003 02:28:49 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2O7STO08976; Mon, 24 Mar 2003 02:28:29 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2O7MaO08522 for ; Mon, 24 Mar 2003 02:22:36 -0500 Received: from sj-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26817 for ; Mon, 24 Mar 2003 02:02:23 -0500 (EST) 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.6/8.12.6) with ESMTP id h2O74e4c019677 for ; Sun, 23 Mar 2003 23:04:40 -0800 (PST) Received: from cj14 (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with SMTP id ACO11122; Sun, 23 Mar 2003 23:04:39 -0800 (PST) From: "Cullen Jennings" To: Date: Sun, 23 Mar 2003 23:05:18 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <200303071154.GAA21633@ietf.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Subject: [Sip] SIP MIB implementations? Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I'm wondering about actual implementation experience with the SIP MIB. Has anyone implemented any version or portion of it? Any operational experience folks could provide on what turned out to be useful? > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of > Internet-Drafts@ietf.org > Sent: Friday, March 07, 2003 3:55 AM > To: IETF-Announce: > Cc: sip@ietf.org > Subject: [Sip] I-D ACTION:draft-ietf-sip-mib-05.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 : Management Information Base for Session > Initiation > Protocol > Author(s) : K. Lingle, J. Maeng, J. Mule, D. Walker > Filename : draft-ietf-sip-mib-05.txt > Pages : 97 > Date : 2003-3-6 > > This memo defines a portion of the Management Information Base (MIB) > for use with network management protocols in the Internet community. > In particular, it describes a set of managed objects that are used > to manage Session Initiation Protocol (SIP) entities, which include > User Agents, Proxy servers, Redirect servers and Registrars. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-sip-mib-05.txt > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body of > the message. > > Internet-Drafts are also available by anonymous FTP. Login with > the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-sip-mib-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-mib-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. > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Mon Mar 24 07:54:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14478 for ; Mon, 24 Mar 2003 07:54:09 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2ODDvc31724 for sip-archive@odin.ietf.org; Mon, 24 Mar 2003 08:13:57 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2ODDOO31687; Mon, 24 Mar 2003 08:13:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OD9oO31547 for ; Mon, 24 Mar 2003 08:09:50 -0500 Received: from hotmail.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13850 for ; Mon, 24 Mar 2003 07:49:31 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 24 Mar 2003 04:51:48 -0800 Received: from 212.143.185.30 by lw15fd.law15.hotmail.msn.com with HTTP; Mon, 24 Mar 2003 12:51:48 GMT X-Originating-IP: [212.143.185.30] X-Originating-Email: [james_s_ford@hotmail.com] From: "James Ford" To: sip@ietf.org Cc: eronstein@hotmail.com Subject: Re: [Sip] TLS post connection verification Date: Mon, 24 Mar 2003 12:51:48 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 24 Mar 2003 12:51:48.0442 (UTC) FILETIME=[22063BA0:01C2F204] Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Hi Eron, The standard does not elaborate on that, but here is what I think: For the second question: for sending responses on broken connections, I don't think that there is a need to do post connection assertion. for two reasons: a - The server does not need to authenticate the client. b - allot of applications put their specific IP address on the via field while a certificate is more likely issued to an FQDN. The first question is more tricky. My guess is the "incoming" connection should only check for the correctness of the certificate and not do a post connection assertion. This might be a security issue though. Maybe someone with some hands on experience can would be more helpful here. Regards, James S. Ford >Hi, > >When sending a request (ie REGISTER) to a server I can compare the request >URI to the common name (or the alt dns name) in the certificate. If the >names match, I can conclude that the certificate is OK. >(I'm using OpenSSL, and they recommend this post connection assertion). > >I have two questions thou: > >1 - What name should I use for comparison when accepting a connection? >Usually only the UAC will demand certificate, I am concerned with te case >of > >two proxies trying to connect using TLS and the UAS proxy asking for client >certificates. (what uri will the UAS proxy has, there is no message yet). > >2 - how should broken connection be handled? lets say UAC1 sent a request >over TLS to UAS1. the handshake went well and the request sent. than for >some reason, the connection was broken and UAS1 now needs to reestablish >the > >connection. What should UAS1 do? use TLS w/out certificates? > > >Regards, >Eron Stein > >_________________________________________________________________ >The new MSN 8: advanced junk mail protection and 2 months FREE* >http://join.msn.com/?page=features/junkmail > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip _________________________________________________________________ Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Mon Mar 24 08:35:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16982 for ; Mon, 24 Mar 2003 08:35:37 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2ODtQf01923 for sip-archive@odin.ietf.org; Mon, 24 Mar 2003 08:55:26 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2ODskO01835; Mon, 24 Mar 2003 08:54:46 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2ODptO01731 for ; Mon, 24 Mar 2003 08:51:55 -0500 Received: from gateway.hns.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16918; Mon, 24 Mar 2003 08:31:34 -0500 (EST) From: aroychow@hss.hns.com Received: from excore1.hns.com (excore1.hns.com [139.85.52.104]) by gateway.hns.com (Switch-3.0.3/Switch-3.0.0) with ESMTP id h2ODXdBO017941; Mon, 24 Mar 2003 08:33:39 -0500 (EST) Received: from atlas (atlas.hns.com [139.85.177.110]) by excore1.hns.com (Switch-2.2.5/Switch-2.2.5) with ESMTP id h2ODXXZ16780; Mon, 24 Mar 2003 08:33:33 -0500 (EST) To: "Cullen Jennings" Cc: sip@ietf.org, sip-admin@ietf.org Subject: Re: [Sip] SIP MIB implementations? MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: Date: Mon, 24 Mar 2003 08:33:34 -0500 X-MIMETrack: Serialize by Router on Atlas/HNS(Release 5.0.10 |March 22, 2002) at 03/24/2003 08:31:36 AM, Serialize complete at 03/24/2003 08:31:36 AM Content-Type: multipart/alternative; boundary="=_alternative 004A79C785256CF3_=" X-Filtered: Sendmail MIME Filter v1.0.8 excore1.hns.com h2ODXXZ16780 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This is a multipart message in MIME format. --=_alternative 004A79C785256CF3_= Content-Type: text/plain; charset="us-ascii" Yes - indeed we have - developed and deployed -> you may want to follow some previous threads of some real-life issues we have been facing wrt. dynamic data (see mail by sshetti@hss.hns.com in archives as a starter). We'd be interested in hearing from deployment experience from others too. regds arjun -- Arjun Roychowdhury @ Hughes Software Systems 11717 Exploration Lane, Germantown MD 20876 (O): 301 212 7860 (M): 240 997 0066{@vtext.com} "Cullen Jennings" Sent by: sip-admin@ietf.org 03/24/2003 02:05 AM To: cc: Subject: [Sip] SIP MIB implementations? I'm wondering about actual implementation experience with the SIP MIB. Has anyone implemented any version or portion of it? Any operational experience folks could provide on what turned out to be useful? > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of > Internet-Drafts@ietf.org > Sent: Friday, March 07, 2003 3:55 AM > To: IETF-Announce: > Cc: sip@ietf.org > Subject: [Sip] I-D ACTION:draft-ietf-sip-mib-05.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 : Management Information Base for Session > Initiation > Protocol > Author(s) : K. Lingle, J. Maeng, J. Mule, D. Walker > Filename : draft-ietf-sip-mib-05.txt > Pages : 97 > Date : 2003-3-6 > > This memo defines a portion of the Management Information Base (MIB) > for use with network management protocols in the Internet community. > In particular, it describes a set of managed objects that are used > to manage Session Initiation Protocol (SIP) entities, which include > User Agents, Proxy servers, Redirect servers and Registrars. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-sip-mib-05.txt > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body of > the message. > > Internet-Drafts are also available by anonymous FTP. Login with > the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-sip-mib-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-mib-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. > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --=_alternative 004A79C785256CF3_= Content-Type: text/html; charset="us-ascii"
Yes - indeed we have - developed and deployed -> you may want to follow some previous threads of some real-life issues
we have been facing wrt. dynamic data (see mail by sshetti@hss.hns.com in archives as a starter). We'd be interested in hearing
from deployment experience from others too.

regds
arjun

--
Arjun Roychowdhury @ Hughes Software Systems
11717 Exploration Lane, Germantown MD 20876
(O): 301 212 7860  (M): 240 997 0066{@vtext.com}


"Cullen Jennings" <fluffy@cisco.com>
Sent by: sip-admin@ietf.org

03/24/2003 02:05 AM

       
        To:        <sip@ietf.org>
        cc:        
        Subject:        [Sip] SIP MIB implementations?




I'm wondering about actual implementation experience with the SIP MIB. Has
anyone implemented any version or portion of it? Any operational experience
folks could provide on what turned out to be useful?



> -----Original Message-----
> From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of
> Internet-Drafts@ietf.org
> Sent: Friday, March 07, 2003 3:55 AM
> To: IETF-Announce:
> Cc: sip@ietf.org
> Subject: [Sip] I-D ACTION:draft-ietf-sip-mib-05.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                                  : Management Information Base for Session
> Initiation
>                           Protocol
>                  Author(s)                 : K. Lingle, J. Maeng, J. Mule, D. Walker
>                  Filename                 : draft-ietf-sip-mib-05.txt
>                  Pages                                  : 97
>                  Date                                  : 2003-3-6
>
> This memo defines a portion of the Management Information Base (MIB)
> for use with network management protocols in the Internet community.
> In particular, it describes a set of managed objects that are used
> to manage Session Initiation Protocol (SIP) entities, which include
> User Agents, Proxy servers, Redirect servers and Registrars.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-sip-mib-05.txt
>
> To remove yourself from the IETF Announcement list, send a message to
> ietf-announce-request with the word unsubscribe in the body of
> the message.
>
> Internet-Drafts are also available by anonymous FTP. Login with
> the username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
>                  "get draft-ietf-sip-mib-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-mib-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.
>

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

--=_alternative 004A79C785256CF3_=-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Mon Mar 24 18:27:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09575 for ; Mon, 24 Mar 2003 18:27:31 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2ONkwO11339 for sip-archive@odin.ietf.org; Mon, 24 Mar 2003 18:46:58 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2ONkOO11314; Mon, 24 Mar 2003 18:46:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2ONg3O11203 for ; Mon, 24 Mar 2003 18:42:03 -0500 Received: from sj-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09406 for ; Mon, 24 Mar 2003 18:21:30 -0500 (EST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h2ONNUmW024314; Mon, 24 Mar 2003 15:23:34 -0800 (PST) Received: from bhadoria-lnx.cisco.com (bhadoria-lnx.cisco.com [128.107.140.160]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id AFB28187; Mon, 24 Mar 2003 15:23:29 -0800 (PST) Date: Mon, 24 Mar 2003 15:23:29 -0800 (PST) From: Amit Bhadoria To: James Ford cc: sip@ietf.org, eronstein@hotmail.com Subject: Re: [Sip] TLS post connection verification In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , answer to these questions depend on whether the connection is intra domain or inter domain. for an intra domain connection, when proxy is talking to its clients, then yes it does'nt need to do post connection authentication unless the clients are capable of it. however, it is recommended that for this intra domain signalling, digest authentication should be used with TLS. hence, this digest over TLS presents a pretty secured model. things are different for inter domain connection though! it makes most sense to perform mutual authentication (post-connection) for inter domain signalling. for client side, its straignt forward. however, RFC also mentions recommendations (section 26.3.2.2) for server side to verify the certificate for domainname portion of the From header. this makes much sense, coz interdomain signalling SHOULD be going thru proxies (which should be able to present certificates), and there should'nt be more than one interdomain hop involved in a sip session establishement. as a side note, its highly unlikely (atleast inefficient) to have parsed the message (for via) while TLS connection is still happening. hence, it makes more sense to authenticate the certificate against the domain of source IP addr in the connection instead of IP addr mention in Via header. regards, -amit. On Mon, 24 Mar 2003, James Ford wrote: > Hi Eron, > The standard does not elaborate on that, but here is what I think: > > For the second question: for sending responses on broken connections, I > don't think that there is a need to do post connection assertion. for two > reasons: > a - The server does not need to authenticate the client. > b - allot of applications put their specific IP address on the via field > while a certificate is more likely issued to an FQDN. > > The first question is more tricky. My guess is the "incoming" connection > should only check for the correctness of the certificate and not do a post > connection assertion. This might be a security issue though. Maybe someone > with some hands on experience can would be more helpful here. > > Regards, > James S. Ford > > > >Hi, > > > >When sending a request (ie REGISTER) to a server I can compare the request > >URI to the common name (or the alt dns name) in the certificate. If the > >names match, I can conclude that the certificate is OK. > >(I'm using OpenSSL, and they recommend this post connection assertion). > > > >I have two questions thou: > > > >1 - What name should I use for comparison when accepting a connection? > >Usually only the UAC will demand certificate, I am concerned with te case > >of > > > >two proxies trying to connect using TLS and the UAS proxy asking for client > >certificates. (what uri will the UAS proxy has, there is no message yet). > > > >2 - how should broken connection be handled? lets say UAC1 sent a request > >over TLS to UAS1. the handshake went well and the request sent. than for > >some reason, the connection was broken and UAS1 now needs to reestablish > >the > > > >connection. What should UAS1 do? use TLS w/out certificates? > > > > > >Regards, > >Eron Stein > > > >_________________________________________________________________ > >The new MSN 8: advanced junk mail protection and 2 months FREE* > >http://join.msn.com/?page=features/junkmail > > > >_______________________________________________ > >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >This list is for NEW development of the core SIP Protocol > >Use sip-implementors@cs.columbia.edu for questions on current sip > >Use sipping@ietf.org for new developments on the application of sip > > > _________________________________________________________________ > Add photos to your e-mail with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > ---------------------------------------------------------------------------- Next to being shot at and missed, nothing is really quite as satisfying as an income tax refund. -- gnulib _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Mon Mar 24 19:05:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10510 for ; Mon, 24 Mar 2003 19:05:56 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2P0Q0813501 for sip-archive@odin.ietf.org; Mon, 24 Mar 2003 19:26:00 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P0PUO13479; Mon, 24 Mar 2003 19:25:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P0MDO13281 for ; Mon, 24 Mar 2003 19:22:13 -0500 Received: from joy.songbird.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10357; Mon, 24 Mar 2003 19:01:39 -0500 (EST) Received: from rshockeybox.shockey.us (h-69-3-5-197.MCLNVA23.covad.net [69.3.5.197]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h2P03gk32696; Mon, 24 Mar 2003 16:03:42 -0800 Message-Id: <5.2.0.9.2.20030324185638.016696c8@popd.ix.netcom.com> X-Sender: richard@shockey.us X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 24 Mar 2003 19:04:17 -0500 To: ietf@ietf.org From: Richard Shockey Cc: sip@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Sip] Eating our own Dog Food...could the IAB and IESG use SIP for conference calls Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Like many of us I was moved my Harald's appeal for suggestions for helping to cut down costs in the IETF. I certainly endorse the idea of considering Canada or Mexico as possible sites for future IETF meetings, but I suspect that the weekly teleconferece calls that the IAB and IESG have represent a significant line item for the Secretariat. In case anyone has not heard, SIP is quite capable of handling this type of task and there are a variety of commercial as well as open source Client User Agents as well as commercial products and services that could help reduce this cost. I'm sure the SIP working group could help the Secretariat identify products and services that could make this essential function more productive and operate at less cost. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Mon Mar 24 19:24:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10977 for ; Mon, 24 Mar 2003 19:24:51 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2P0irs15098 for sip-archive@odin.ietf.org; Mon, 24 Mar 2003 19:44:53 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P0iPO15037; Mon, 24 Mar 2003 19:44:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P0f3O14908 for ; Mon, 24 Mar 2003 19:41:03 -0500 Received: from mail4.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10876 for ; Mon, 24 Mar 2003 19:20:31 -0500 (EST) Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h2P0LrTU004461 for ; Mon, 24 Mar 2003 19:21:53 -0500 (EST) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 24 Mar 2003 18:21:58 -0600 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A645CD@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'sip@ietf.org'" Date: Mon, 24 Mar 2003 18:21:51 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] RE: [Simple] [Fwd: RE: SIP WG bugzilla instance] Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , I like it. A lot. I would strongly endorse its use by any and all working groups for tracking bugs in published RFCs and working group items. /a > -----Original Message----- > From: Robert Sparks [mailto:rsparks@dynamicsoft.com] > Sent: Wednesday, March 19, 2003 14:56 > To: sip@ietf.org; simple@ietf.org; sipping@ietf.org > Subject: [Simple] [Fwd: RE: SIP WG bugzilla instance] > > > All - > > I apologize now for violating the no-crosspost policy, but > this spans all the groups. Please, please, reply _ONLY_ to > sip@ietf.org (which is what should happen if you hit your > reply button if I've built this message correctly). > > If you have any opinions, positive or negative, about our > use of bugzilla for issue tracking and whether other groups > should follow the model, now would be a good time to comment. > > Thanks! > > RjS > > -----Forwarded Message----- > > > From: john.loughney@nokia.com > > To: rsparks@dynamicsoft.com, wgchairs@ietf.org > > Subject: RE: SIP WG bugzilla instance > > Date: 19 Mar 2003 22:46:52 +0200 > > > > Robert, > > > > Any comments on how the WG & WG Chairs like it? > > > > John > > > > > At the session on improving working group chair training > > > (and chair effectiveness), tools came up. The SIP related > > > working groups have been effectively using a bugzilla variant > > > to track document issues and help drive open issues to > > > conclusion. > > > > > > It's available at http://www.sipwg.org (or http://bugs.sipit.net). > > > > > > One point to bring forth at the beginning - we use this as > > > a tracking tool, not an alternative venue for list discussion. > > > Document/issue owners are able to make changes to a bug - > > > people ask the owner to add things to the tracking tool on > > > the appropriate list. The chairs make sure that the owners > > > accurately capture threads on the tracking tool. > > > > > > RjS > > > > > > > > > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Tue Mar 25 00:19:52 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18613 for ; Tue, 25 Mar 2003 00:19:52 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2P5e1x03574 for sip-archive@odin.ietf.org; Tue, 25 Mar 2003 00:40:01 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P5dJO03509; Tue, 25 Mar 2003 00:39:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P5ZjO02641 for ; Tue, 25 Mar 2003 00:35:45 -0500 Received: from sj-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18563 for ; Tue, 25 Mar 2003 00:15:04 -0500 (EST) Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h2P5HImU015886; Mon, 24 Mar 2003 21:17:22 -0800 (PST) Received: from cj14 (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with SMTP id ACP04696; Mon, 24 Mar 2003 21:17:18 -0800 (PST) From: "Cullen Jennings" To: "Eron Stein" , Subject: RE: [Sip] TLS post connection verification Date: Mon, 24 Mar 2003 21:17:59 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-reply-to: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit If element A wants to send a SIP message over TLS to a next hop called foo.com, A needs to check that the SubjectAltName in the certificate provided over the TLS connection to A matches foo.com. Openssl can not do this for you automatically, A needs to call the SSL_get_peer_certificate after A has connected. foo.com may request, and look at, the certificate of A or may not depending on if mutual TLS is being done or not. There is very little point in using TLS if you don't check that the server you connected to is the server you meant to connect to. If all you know is the IP address of the server and the server presents a certificate with a FQDN, you are pretty much out of luck. Cullen > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Eron > Stein > Sent: Wednesday, March 19, 2003 6:14 AM > To: sip@ietf.org > Subject: [Sip] TLS post connection verification > > > Hi, > > When sending a request (ie REGISTER) to a server I can compare > the request > URI to the common name (or the alt dns name) in the certificate. If the > names match, I can conclude that the certificate is OK. > (I'm using OpenSSL, and they recommend this post connection assertion). > > I have two questions thou: > > 1 - What name should I use for comparison when accepting a connection? > Usually only the UAC will demand certificate, I am concerned with > te case of > two proxies trying to connect using TLS and the UAS proxy asking > for client > certificates. (what uri will the UAS proxy has, there is no message yet). > > 2 - how should broken connection be handled? lets say UAC1 sent a request > over TLS to UAS1. the handshake went well and the request sent. than for > some reason, the connection was broken and UAS1 now needs to > reestablish the > connection. What should UAS1 do? use TLS w/out certificates? > > > Regards, > Eron Stein > > _________________________________________________________________ > The new MSN 8: advanced junk mail protection and 2 months FREE* > http://join.msn.com/?page=features/junkmail > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Tue Mar 25 01:27:28 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19526 for ; Tue, 25 Mar 2003 01:27:27 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2P6lcn07094 for sip-archive@odin.ietf.org; Tue, 25 Mar 2003 01:47:38 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P6lBO07069; Tue, 25 Mar 2003 01:47:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P6h3O06951 for ; Tue, 25 Mar 2003 01:43:03 -0500 Received: from romeo.rtfm.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19464 for ; Tue, 25 Mar 2003 01:22:21 -0500 (EST) Received: by romeo.rtfm.com (Postfix, from userid 556) id 55311AB6D; Mon, 24 Mar 2003 22:30:08 -0800 (PST) To: "Cullen Jennings" Cc: "Eron Stein" , Subject: Re: [Sip] TLS post connection verification References: Reply-To: EKR From: Eric Rescorla Date: 24 Mar 2003 22:30:08 -0800 In-Reply-To: Message-ID: Lines: 20 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Cuyahoga Valley) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , "Cullen Jennings" writes: > If element A wants to send a SIP message over TLS to a next hop called > foo.com, A needs to check that the SubjectAltName in the certificate > provided over the TLS connection to A matches foo.com. Openssl can not do > this for you automatically, A needs to call the SSL_get_peer_certificate > after A has connected. foo.com may request, and look at, the certificate of > A or may not depending on if mutual TLS is being done or not. Exactly. > There is very little point in using TLS if you don't check that the server > you connected to is the server you meant to connect to. If all you know is > the IP address of the server and the server presents a certificate with a > FQDN, you are pretty much out of luck. Just to be clear, it depends on your threat model. If you believe that only passive attacks will be mounted, then TLS is worth something even without checking the certificates. However, active attacks are getting easier to mount... -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 mailnull@www1.ietf.org Tue Mar 25 09:52:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14747 for ; Tue, 25 Mar 2003 09:52:37 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2PFCvw17912 for sip-archive@odin.ietf.org; Tue, 25 Mar 2003 10:12:57 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PFCAO17873; Tue, 25 Mar 2003 10:12:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PF6aO16861 for ; Tue, 25 Mar 2003 10:06:36 -0500 Received: from pmesmtp01.wcom.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14487; Tue, 25 Mar 2003 09:45:45 -0500 (EST) Received: from pmismtp06.wcomnet.com ([166.38.62.54]) by firewall.wcom.com (Iplanet MTA 5.2) with ESMTP id <0HCB0072F7Q375@firewall.wcom.com>; Tue, 25 Mar 2003 14:46:51 +0000 (GMT) Received: from pmismtp06.wcomnet.com by pmismtp06.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0HCB00D017HNTP@pmismtp06.wcomnet.com>; Tue, 25 Mar 2003 14:46:51 +0000 (GMT) Received: from hsinnreich2 ([166.50.96.188]) by pmismtp06.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0HCB00DI67PBJB@pmismtp06.wcomnet.com>; Tue, 25 Mar 2003 14:46:24 +0000 (GMT) Date: Tue, 25 Mar 2003 08:46:23 -0600 From: Henry Sinnreich Subject: RE: [Sip] Eating our own Dog Food...could the IAB and IESG use SIP for conference calls In-reply-to: <5.2.0.9.2.20030324185638.016696c8@popd.ix.netcom.com> To: "'Richard Shockey'" , ietf@ietf.org Cc: sip@ietf.org, Scott Petrack , Christian Stredicke Message-id: <000001c2f2dd$4f03d2a0$bc6032a6@hsinnreich2> Organization: WorldCom, Inc. MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook, Build 10.0.3416 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit There are excellent SIP voice conferencing bridges available, such as from snom AG and eDial. They can be used with various soft clients such as the Windows Messenger, HotSIP Active Contacts or the Pingtel instant expressa, or any SIP phone. I have taken the liberty of copying here the contacts for snom AG and eDial, in case this will be pursued. I wonder if snom AG or eDial would just give the IESG and IAB access to their conference servers? Would there be interest to have access to a WorldCom SIP conference bridge? Thanks, Henry > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On > Behalf Of Richard Shockey > Sent: Monday, March 24, 2003 6:04 PM > To: ietf@ietf.org > Cc: sip@ietf.org > Subject: [Sip] Eating our own Dog Food...could the IAB and > IESG use SIP for conference calls > > > > Like many of us I was moved my Harald's appeal for > suggestions for helping > to cut down costs in the IETF. > > I certainly endorse the idea of considering Canada or Mexico > as possible > sites for future IETF meetings, but I suspect that the weekly > teleconferece > calls that the IAB and IESG have represent a significant line > item for the > Secretariat. > > In case anyone has not heard, SIP is quite capable of > handling this type of > task and there are a variety of commercial as well as open > source Client > User Agents as well as commercial products and services that > could help > reduce this cost. > > I'm sure the SIP working group could help the Secretariat > identify products > and services that could make this essential function more > productive and > operate at less cost. > > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > Richard Shockey, Senior Manager, Strategic Technology > Initiatives NeuStar Inc. > 46000 Center Oak Plaza - Sterling, VA 20166 > Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 > 815.333.1237 > or > ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Tue Mar 25 10:03:34 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15637 for ; Tue, 25 Mar 2003 10:03:34 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2PFNt118316 for sip-archive@odin.ietf.org; Tue, 25 Mar 2003 10:23:55 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PFNOO18298; Tue, 25 Mar 2003 10:23:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PFK8O18209 for ; Tue, 25 Mar 2003 10:20:08 -0500 Received: from fox.iptel.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15084; Tue, 25 Mar 2003 09:59:12 -0500 (EST) Received: by fox.iptel.org (Postfix, from userid 534) id 9E9261FF; Tue, 25 Mar 2003 16:01:28 +0100 (CET) Received: from jku07.fokus.fraunhofer.de (dhcp186.fokus.fraunhofer.de [195.37.78.186]) by fox.iptel.org (Postfix) with ESMTP id 3C6281FF; Tue, 25 Mar 2003 16:01:27 +0100 (CET) Message-Id: <5.2.0.9.0.20030325160020.058e6310@mailhost.fokus.gmd.de> X-Sender: jku@mailhost.fokus.gmd.de (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 25 Mar 2003 16:01:10 +0100 To: Henry Sinnreich , "'Richard Shockey'" , ietf@ietf.org From: Jiri Kuthan Subject: RE: [Sip] Eating our own Dog Food...could the IAB and IESG use SIP for conference calls Cc: sip@ietf.org, Scott Petrack , Christian Stredicke In-Reply-To: <000001c2f2dd$4f03d2a0$bc6032a6@hsinnreich2> References: <5.2.0.9.2.20030324185638.016696c8@popd.ix.netcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Status: No, hits=-19.9 required=5.0 tests=AWL,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.51 X-Spam-Checker-Version: SpamAssassin 2.51 (1.174.2.5-2003-03-20-exp) Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , That's great idea. We can help with our free SIP server (www.iptel.org/ser/) and hosting the services. -Jiri At 03:46 PM 3/25/2003, Henry Sinnreich wrote: >There are excellent SIP voice conferencing bridges available, such as >from snom AG and eDial. They can be used with various soft clients such >as the Windows Messenger, HotSIP Active Contacts or the Pingtel instant >expressa, or any SIP phone. > >I have taken the liberty of copying here the contacts for snom AG and >eDial, in case this will be pursued. I wonder if snom AG or eDial would >just give the IESG and IAB access to their conference servers? > >Would there be interest to have access to a WorldCom SIP conference >bridge? > >Thanks, Henry > >> -----Original Message----- >> From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On >> Behalf Of Richard Shockey >> Sent: Monday, March 24, 2003 6:04 PM >> To: ietf@ietf.org >> Cc: sip@ietf.org >> Subject: [Sip] Eating our own Dog Food...could the IAB and >> IESG use SIP for conference calls >> >> >> >> Like many of us I was moved my Harald's appeal for >> suggestions for helping >> to cut down costs in the IETF. >> >> I certainly endorse the idea of considering Canada or Mexico >> as possible >> sites for future IETF meetings, but I suspect that the weekly >> teleconferece >> calls that the IAB and IESG have represent a significant line >> item for the >> Secretariat. >> >> In case anyone has not heard, SIP is quite capable of >> handling this type of >> task and there are a variety of commercial as well as open >> source Client >> User Agents as well as commercial products and services that >> could help >> reduce this cost. >> >> I'm sure the SIP working group could help the Secretariat >> identify products >> and services that could make this essential function more >> productive and >> operate at less cost. >> >> >> >> >> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >> Richard Shockey, Senior Manager, Strategic Technology >> Initiatives NeuStar Inc. >> 46000 Center Oak Plaza - Sterling, VA 20166 >> Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 >> 815.333.1237 > or >> > > ; ><<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip Use >sipping@ietf.org for new developments on the application of sip > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Tue Mar 25 10:40:54 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18705 for ; Tue, 25 Mar 2003 10:40:54 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2PG1FB21065 for sip-archive@odin.ietf.org; Tue, 25 Mar 2003 11:01:15 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PG0mO20959; Tue, 25 Mar 2003 11:00:48 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PFv1O20748 for ; Tue, 25 Mar 2003 10:57:01 -0500 Received: from radvpost.RADVISION.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18470; Tue, 25 Mar 2003 10:36:08 -0500 (EST) Received: by radvpost.radvision.com with Internet Mail Service (5.5.2653.19) id ; Tue, 25 Mar 2003 10:36:45 -0500 Message-ID: From: Orit Levin To: "'Henry Sinnreich'" , "'Richard Shockey'" , ietf@ietf.org Cc: sip@ietf.org Subject: RE: [Sip] Eating our own Dog Food...could the IAB and IESG use SI P for conference calls Date: Tue, 25 Mar 2003 10:36:44 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , We can provide a voice and/or VIDEO conferencing service interconnecting all kinds of voice and video applications in a single conference from/to our NJ "production lab". That includes SIP voice-only and multimedia (such as Messenger) end points. BR, Orit Levin Chief Architect RADVISION Phone: +1.201.6896330 Video: +1.201.6896430 > -----Original Message----- > From: Henry Sinnreich [mailto:Henry.Sinnreich@wcom.com] > Sent: Tuesday, March 25, 2003 9:46 AM > To: 'Richard Shockey'; ietf@ietf.org > Cc: sip@ietf.org; Scott Petrack; Christian Stredicke > Subject: RE: [Sip] Eating our own Dog Food...could the IAB and IESG use > SIP for conference calls > > There are excellent SIP voice conferencing bridges available, such as > from snom AG and eDial. They can be used with various soft clients such > as the Windows Messenger, HotSIP Active Contacts or the Pingtel instant > expressa, or any SIP phone. > > I have taken the liberty of copying here the contacts for snom AG and > eDial, in case this will be pursued. I wonder if snom AG or eDial would > just give the IESG and IAB access to their conference servers? > > Would there be interest to have access to a WorldCom SIP conference > bridge? > > Thanks, Henry > > > -----Original Message----- > > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On > > Behalf Of Richard Shockey > > Sent: Monday, March 24, 2003 6:04 PM > > To: ietf@ietf.org > > Cc: sip@ietf.org > > Subject: [Sip] Eating our own Dog Food...could the IAB and > > IESG use SIP for conference calls > > > > > > > > Like many of us I was moved my Harald's appeal for > > suggestions for helping > > to cut down costs in the IETF. > > > > I certainly endorse the idea of considering Canada or Mexico > > as possible > > sites for future IETF meetings, but I suspect that the weekly > > teleconferece > > calls that the IAB and IESG have represent a significant line > > item for the > > Secretariat. > > > > In case anyone has not heard, SIP is quite capable of > > handling this type of > > task and there are a variety of commercial as well as open > > source Client > > User Agents as well as commercial products and services that > > could help > > reduce this cost. > > > > I'm sure the SIP working group could help the Secretariat > > identify products > > and services that could make this essential function more > > productive and > > operate at less cost. > > > > > > > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > > Richard Shockey, Senior Manager, Strategic Technology > > Initiatives NeuStar Inc. > > 46000 Center Oak Plaza - Sterling, VA 20166 > > Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 > > 815.333.1237 > or > > > > ; > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip Use > sipping@ietf.org for new developments on the application of sip > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Tue Mar 25 10:43:18 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18784 for ; Tue, 25 Mar 2003 10:43:17 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2PG3d221172 for sip-archive@odin.ietf.org; Tue, 25 Mar 2003 11:03:39 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PG3FO21154; Tue, 25 Mar 2003 11:03:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PG0aO20940 for ; Tue, 25 Mar 2003 11:00:36 -0500 Received: from yyc.jasomi.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18657; Tue, 25 Mar 2003 10:39:43 -0500 (EST) Received: from DANSLIFEBOOK (h68-144-56-154.cg.shawcable.net [68.144.56.154]) (authenticated bits=0) by yyc.jasomi.com (8.12.6/8.12.6) with ESMTP id h2PFfubu030458 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 25 Mar 2003 08:41:58 -0700 (MST) Message-Id: <200303251541.h2PFfubu030458@yyc.jasomi.com> Reply-To: From: "Dan Freedman" To: Cc: Subject: RE: [Sip] Eating our own Dog Food...could the IAB and IESG use SIP for conference calls Date: Tue, 25 Mar 2003 08:43:59 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailer: Microsoft Outlook, Build 11.0.4920 In-Reply-To: <5.2.0.9.0.20030325160020.058e6310@mailhost.fokus.gmd.de> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Thread-Index: AcLy3/FQhmlpjnuZQhOr7Tlb31GbUgAA7JIQ Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2PG0aO20941 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Agreed. To enable access from behind firewalls (ie: homes, hotels, conferences, airports, Asia, ...), we can donate a B2BUA-based NAT traversal solution for SIP (same one that Pulver's Free World Dialup uses). It sits near the proxy, with nothing needed on the client end. Bottom line: In addition to helping the IESG and IAB, it will help SIP to have more IETF participants gaining experience with it. -Dan Dan Freedman, CEO, Jasomi Networks, Inc. 2033 Gateway Place, Suite 500, San Jose, CA, 95110 Phone +1.403.680.2351 Fax +1.403.269.2993 Email dan@jasomi.com SIP dan@jasomi.com Web www.jasomi.com -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of Jiri Kuthan Sent: Tuesday, March 25, 2003 8:01 AM To: Henry Sinnreich; 'Richard Shockey'; ietf@ietf.org Cc: sip@ietf.org; Scott Petrack; Christian Stredicke That's great idea. We can help with our free SIP server (www.iptel.org/ser/) and hosting the services. -Jiri At 03:46 PM 3/25/2003, Henry Sinnreich wrote: >There are excellent SIP voice conferencing bridges available, such as >from snom AG and eDial. They can be used with various soft clients such >as the Windows Messenger, HotSIP Active Contacts or the Pingtel instant >expressa, or any SIP phone. > >I have taken the liberty of copying here the contacts for snom AG and >eDial, in case this will be pursued. I wonder if snom AG or eDial would >just give the IESG and IAB access to their conference servers? > >Would there be interest to have access to a WorldCom SIP conference >bridge? > >Thanks, Henry > >> -----Original Message----- >> From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On >> Behalf Of Richard Shockey >> Sent: Monday, March 24, 2003 6:04 PM >> To: ietf@ietf.org >> Cc: sip@ietf.org >> Subject: [Sip] Eating our own Dog Food...could the IAB and >> IESG use SIP for conference calls >> >> >> >> Like many of us I was moved my Harald's appeal for >> suggestions for helping >> to cut down costs in the IETF. >> >> I certainly endorse the idea of considering Canada or Mexico >> as possible >> sites for future IETF meetings, but I suspect that the weekly >> teleconferece >> calls that the IAB and IESG have represent a significant line >> item for the >> Secretariat. >> >> In case anyone has not heard, SIP is quite capable of >> handling this type of >> task and there are a variety of commercial as well as open >> source Client >> User Agents as well as commercial products and services that >> could help >> reduce this cost. >> >> I'm sure the SIP working group could help the Secretariat >> identify products >> and services that could make this essential function more >> productive and >> operate at less cost. >> >> >> >> >> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >> Richard Shockey, Senior Manager, Strategic Technology >> Initiatives NeuStar Inc. >> 46000 Center Oak Plaza - Sterling, VA 20166 >> Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 >> 815.333.1237 > or >> > > ; ><<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Tue Mar 25 12:53:16 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23029 for ; Tue, 25 Mar 2003 12:53:16 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2PIDeS31494 for sip-archive@odin.ietf.org; Tue, 25 Mar 2003 13:13:40 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PI9sO31331; Tue, 25 Mar 2003 13:09:54 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PI4eO30326 for ; Tue, 25 Mar 2003 13:04:40 -0500 Received: from mail.cit.ie (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22819 for ; Tue, 25 Mar 2003 12:43:45 -0500 (EST) Received: from EEB174W2Kvk (unverified [157.190.81.172]) by cit.ie (Rockliffe SMTPRA 5.2.5) with SMTP id for ; Tue, 25 Mar 2003 17:47:03 +0000 Reply-To: From: "Valerie Kenneally" To: Date: Tue, 25 Mar 2003 17:46:05 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Content-Transfer-Encoding: 7bit Subject: [Sip] Registration Query Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi all, Assume a User Agent is registering with a SIP Server. The SIP Server challenges the User Agent with regard to Authorization. The User Agent replies with the appropriate information. My question-when the User Agent responds to the challenge will the Call-ID and From tag or this message be the same as the first REGISTER message sent? All info greatly accepted! -------------------Legal Disclaimer--------------------------------------- The above electronic mail transmission is confidential and intended only for the person to whom it is addressed. Its contents may be protected by legal and/or professional privilege. Should it be received by you in error please contact the sender at the above quoted email address. Any unauthorised form of reproduction of this message is strictly prohibited. The Institute does not guarantee the security of any information electronically transmitted and is not liable if the information contained in this communication is not a proper and complete record of the message as transmitted by the sender nor for any delay in its receipt. ---------------------------------------------------------------------------------------- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Tue Mar 25 14:23:24 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26692 for ; Tue, 25 Mar 2003 14:23:24 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2PJhmh05909 for sip-archive@odin.ietf.org; Tue, 25 Mar 2003 14:43:48 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PJfwO05802; Tue, 25 Mar 2003 14:41:58 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PJWFO04476 for ; Tue, 25 Mar 2003 14:32:15 -0500 Received: from eikenes.alvestrand.no (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25945; Tue, 25 Mar 2003 14:11:18 -0500 (EST) Received: from [192.168.1.4] (askvoll.hjemme.alvestrand.no [192.168.1.4]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3635262207; Tue, 25 Mar 2003 20:13:37 +0100 (CET) Date: Tue, 25 Mar 2003 20:13:37 +0100 From: Harald Tveit Alvestrand To: Richard Shockey , ietf@ietf.org Cc: sip@ietf.org Subject: Re: [Sip] Eating our own Dog Food...could the IAB and IESG use SIP for conference calls Message-ID: <711640000.1048619617@askvoll.hjemme.alvestrand.no> In-Reply-To: <5.2.0.9.2.20030324185638.016696c8@popd.ix.netcom.com> References: <5.2.0.9.2.20030324185638.016696c8@popd.ix.netcom.com> X-Mailer: Mulberry/2.2.1 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Thanks for the idea! injecting a slight dash of cold water.... - the actual cost of "Teleconferences and Long Distance charges" in 2002 were USD 82.210 (unaudited) (vs 54.400 for 2001). A significant fraction of that, but far from all, is the IESG teleconferences. - we've already switched teleconference providers once to reduce costs, going from call-everyone to most-people-call-in. - the costliest part of the IESG teleconferences has been the callout: international participants (last year, France, the Netherlands, Norway and Sweden when they are at home, hotels literally anywhere in the world when they are travelling) are called rather than calling in. You don't want to discuss with your boss why you had to make a 2 1/2 hour international call at hotel room rates if you can avoid it...... - it's absolutely essential that one be able to participate in the IESG telecon from just about anything that one can dial from - we've had participants on cellphones from trains, in airport lounges, hotel rooms and other places. So SIP-only won't work for some time yet. - even at work, several of us have problems with firewalls; about half the IESG uses Jabber during sessions - the reason many of the others don't is that they can't get Jabber through their corporate firewalls. So "pure Internet SIP" won't work for all of us any time soon. So I think this is a good idea, PROVIDED THAT: - The SIP teleconference bridge provider is able to provide either 800-number access or callout services to normal telephones in most corners of the world - The voice quality, operator quality and call stability is competitive (yes, we've got the "there's an echo on this conference - can you figure out who is echoing and fix it" request down to a matter of routine) A "normal" teleconference provider that *also* allows SIP dialin over the Internet would probably be perfect. If you have one - send email to me - PRIVATELY - and I will forward to the relevant parties at the secretariat. Harald --On mandag, mars 24, 2003 19:04:17 -0500 Richard Shockey wrote: > > Like many of us I was moved my Harald's appeal for suggestions for > helping to cut down costs in the IETF. > > I certainly endorse the idea of considering Canada or Mexico as possible > sites for future IETF meetings, but I suspect that the weekly > teleconferece calls that the IAB and IESG have represent a significant > line item for the Secretariat. > > In case anyone has not heard, SIP is quite capable of handling this type > of task and there are a variety of commercial as well as open source > Client User Agents as well as commercial products and services that could > help reduce this cost. > > I'm sure the SIP working group could help the Secretariat identify > products and services that could make this essential function more > productive and operate at less cost. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Tue Mar 25 17:47:30 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08048 for ; Tue, 25 Mar 2003 17:47:30 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2PN80R24880 for sip-archive@odin.ietf.org; Tue, 25 Mar 2003 18:08:00 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PN5JO23990; Tue, 25 Mar 2003 18:05:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PMtoO23411 for ; Tue, 25 Mar 2003 17:55:50 -0500 Received: from dgesmtp02.wcom.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07284; Tue, 25 Mar 2003 17:34:48 -0500 (EST) Received: from dgismtp03.wcomnet.com ([166.38.58.143]) by firewall.wcom.com (Iplanet MTA ) with ESMTP id <0HCB00ARWTHW5B@firewall.wcom.com>; Tue, 25 Mar 2003 22:37:09 +0000 (GMT) Received: from dgismtp03.wcomnet.com by dgismtp03.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0HCB00801TDECJ@dgismtp03.wcomnet.com>; Tue, 25 Mar 2003 22:37:08 +0000 (GMT) Received: from hsinnreich2 ([166.35.136.36]) by dgismtp03.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0HCB006DCTGDCO@dgismtp03.wcomnet.com>; Tue, 25 Mar 2003 22:36:25 +0000 (GMT) Date: Tue, 25 Mar 2003 16:36:14 -0600 From: Henry Sinnreich Subject: RE: [Sip] Eating our own Dog Food...could the IAB and IESG use SIP for conference calls In-reply-to: <711640000.1048619617@askvoll.hjemme.alvestrand.no> To: "'Harald Tveit Alvestrand'" , "'Richard Shockey'" , ietf@ietf.org Cc: sip@ietf.org Message-id: <001001c2f31e$f862fb00$248823a6@hsinnreich2> Organization: WorldCom, Inc. MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook, Build 10.0.3416 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit >So "pure Internet SIP" won't work for all of us any time soon. Glad to clear up the confusion on this point. People on the PSTN can dial in and can be called from the SIP conferencing server by using a service provider that has standard PSTN-SIP gateways. The typical SIP voice conference has both PSTN users and SIP users. Works quite well for everybody. IM can also be used at the same time, by those who prefer it to real time voice. Several SIP clients do both, actually video and data as well. Thanks, Henry > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On > Behalf Of Harald Tveit Alvestrand > Sent: Tuesday, March 25, 2003 1:14 PM > To: Richard Shockey; ietf@ietf.org > Cc: sip@ietf.org > Subject: Re: [Sip] Eating our own Dog Food...could the IAB > and IESG use SIP for conference calls > > > Thanks for the idea! > injecting a slight dash of cold water.... > > - the actual cost of "Teleconferences and Long Distance > charges" in 2002 > were USD 82.210 (unaudited) (vs 54.400 for 2001). A > significant fraction of > that, but far from all, is the IESG teleconferences. > - we've already switched teleconference providers once to > reduce costs, > going from call-everyone to most-people-call-in. > - the costliest part of the IESG teleconferences has been the > callout: > international participants (last year, France, the > Netherlands, Norway and > Sweden when they are at home, hotels literally anywhere in > the world when > they are travelling) are called rather than calling in. You > don't want to > discuss with your boss why you had to make a 2 1/2 hour > international call > at hotel room rates if you can avoid it...... > - it's absolutely essential that one be able to participate > in the IESG > telecon from just about anything that one can dial from - we've had > participants on cellphones from trains, in airport lounges, > hotel rooms and > other places. So SIP-only won't work for some time yet. > - even at work, several of us have problems with firewalls; > about half the > IESG uses Jabber during sessions - the reason many of the > others don't is > that they can't get Jabber through their corporate firewalls. > So "pure > Internet SIP" won't work for all of us any time soon. > > So I think this is a good idea, PROVIDED THAT: > > - The SIP teleconference bridge provider is able to provide either > 800-number access or callout services to normal telephones in > most corners > of the world > - The voice quality, operator quality and call stability is > competitive > (yes, we've got the "there's an echo on this conference - can > you figure > out who is echoing and fix it" request down to a matter of routine) > > A "normal" teleconference provider that *also* allows SIP > dialin over the > Internet would probably be perfect. If you have one - send > email to me - > PRIVATELY - and I will forward to the relevant parties at the > secretariat. > > Harald > > --On mandag, mars 24, 2003 19:04:17 -0500 Richard Shockey > wrote: > > > > > Like many of us I was moved my Harald's appeal for suggestions for > > helping to cut down costs in the IETF. > > > > I certainly endorse the idea of considering Canada or Mexico as > > possible sites for future IETF meetings, but I suspect that > the weekly > > teleconferece calls that the IAB and IESG have represent a > significant > > line item for the Secretariat. > > > > In case anyone has not heard, SIP is quite capable of handling this > > type of task and there are a variety of commercial as well as open > > source Client User Agents as well as commercial products > and services > > that could help reduce this cost. > > > > I'm sure the SIP working group could help the Secretariat identify > > products and services that could make this essential function more > > productive and operate at less cost. > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current > sip Use sipping@ietf.org for new developments on the > application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Wed Mar 26 08:10:38 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24666 for ; Wed, 26 Mar 2003 08:10:38 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2QDVQK27740 for sip-archive@odin.ietf.org; Wed, 26 Mar 2003 08:31:26 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QDRaO27444; Wed, 26 Mar 2003 08:27:36 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QDN3O27139 for ; Wed, 26 Mar 2003 08:23:03 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24433 for ; Wed, 26 Mar 2003 08:01:43 -0500 (EST) From: Gabor.Bajko@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.5/Switch-2.2.5) with ESMTP id h2QD7rX17743 for ; Wed, 26 Mar 2003 15:07:53 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 26 Mar 2003 15:04:04 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 26 Mar 2003 15:04:04 +0200 Received: from esebe017.NOE.Nokia.com ([172.21.138.56]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 26 Mar 2003 15:04:04 +0200 Received: from buebe002.NOE.Nokia.com ([10.211.0.51]) by esebe017.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 26 Mar 2003 15:04:03 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Wed, 26 Mar 2003 14:04:03 +0100 Message-ID: Thread-Topic: [Sip] Eating our own Dog Food...could the IAB and IESG use SIP for conference calls Thread-Index: AcLzIb2iFM2+hPqxS22mjSckZfSBXAAZEtDQ To: X-OriginalArrivalTime: 26 Mar 2003 13:04:03.0922 (UTC) FILETIME=[2D3B1320:01C2F398] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2QDN3O27140 Subject: [Sip] Question on RFC3329 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit RFC3329, section 2.3.1 says: " The server MUST check that the security mechanisms listed in the Security-Verify header field of incoming requests correspond to its static list of supported security mechanisms.", and further down: " The server can proceed processing a particular request if, and only if, the list was not modified. If modification of the list is detected, the server MUST respond to the client with a 494 (Security Agreement Required) response." In case of Digest this makes sense. But in case the agreed security mechanism is IPSec or TLS, then the SIP layer will only receive the request if it was sent according to the previously agreed security rules (otherwise the lower layers discard it). So, even in case the Security Verify header is altered (e.g. mistakenly at insertion by the UA), the request passed the security checks. Then why the server must respond with 494 instead of accepting it? Shouldn't that MUST be a SHOULD instead, as the server knows how reliable the security mechanism they agreed is without the Security-Verify content? /Gabor _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Wed Mar 26 08:37:15 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25464 for ; Wed, 26 Mar 2003 08:37:15 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2QDw4e29712 for sip-archive@odin.ietf.org; Wed, 26 Mar 2003 08:58:04 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QDsUO29542; Wed, 26 Mar 2003 08:54:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QDpJO29442 for ; Wed, 26 Mar 2003 08:51:19 -0500 Received: from p2.piuha.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25279 for ; Wed, 26 Mar 2003 08:29:59 -0500 (EST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id A0F386A901; Wed, 26 Mar 2003 15:32:19 +0200 (EET) Message-ID: <3E81ABB7.9000508@piuha.net> Date: Wed, 26 Mar 2003 15:31:35 +0200 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/20030211 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Gabor.Bajko@nokia.com Cc: sip@ietf.org Subject: Re: [Sip] Question on RFC3329 References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Gabor.Bajko@nokia.com wrote: > RFC3329, section 2.3.1 says: > > " The server MUST check that the security mechanisms listed in the > Security-Verify header field of incoming requests correspond to its > static list of supported security mechanisms.", and further down: > > " The server can proceed processing a particular request if, and only > if, the list was not modified. If modification of the list is > detected, the server MUST respond to the client with a 494 (Security > Agreement Required) response." > > In case of Digest this makes sense. But in case the agreed security mechanism is IPSec or TLS, then the SIP layer will only receive the request if it was sent according to the previously agreed security rules (otherwise the lower layers discard it). So, even in case the Security Verify header is altered (e.g. mistakenly at insertion by the UA), the request passed the security checks. Then why the server must respond with 494 instead of accepting it? > > Shouldn't that MUST be a SHOULD instead, as the server knows how reliable the security mechanism they agreed is without the Security-Verify content? We discussed this while the draft was being worked on. In principle you are right, but we felt that it would be better to make the behaviour the same in all cases without special cases. Jari _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Wed Mar 26 08:57:33 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26360 for ; Wed, 26 Mar 2003 08:57:33 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2QEIML31856 for sip-archive@odin.ietf.org; Wed, 26 Mar 2003 09:18:22 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QEEdO31519; Wed, 26 Mar 2003 09:14:39 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QEBnO31368 for ; Wed, 26 Mar 2003 09:11:49 -0500 Received: from hotmail.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26088 for ; Wed, 26 Mar 2003 08:50:29 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 26 Mar 2003 05:52:49 -0800 Received: from 212.143.185.30 by lw15fd.law15.hotmail.msn.com with HTTP; Wed, 26 Mar 2003 13:52:49 GMT X-Originating-IP: [212.143.185.30] X-Originating-Email: [james_s_ford@hotmail.com] From: "James Ford" To: sip@ietf.org Date: Wed, 26 Mar 2003 13:52:49 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 26 Mar 2003 13:52:49.0810 (UTC) FILETIME=[FD322720:01C2F39E] Subject: [Sip] The term UA Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Hi, When a single phone is used by several users, do we refer to each user as a seperate UA or do we refer to the phone as the UA? Thanks, James. _________________________________________________________________ Help STOP SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Thu Mar 27 06:54:20 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24027 for ; Thu, 27 Mar 2003 06:54:19 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2RCFZ510874 for sip-archive@odin.ietf.org; Thu, 27 Mar 2003 07:15:35 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2RCEuO10837; Thu, 27 Mar 2003 07:14:56 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2RC6uO09804 for ; Thu, 27 Mar 2003 07:06:56 -0500 Received: from sm.luth.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23872 for ; Thu, 27 Mar 2003 06:45:10 -0500 (EST) Received: from cdt.luth.se (blipp.cdt.luth.se [130.240.64.67]) by sm.luth.se (8.12.8/8.12.3) with ESMTP id h2RBlTWm027520 for ; Thu, 27 Mar 2003 12:47:29 +0100 (MET) Message-ID: <3E82E4D8.F3B780BC@cdt.luth.se> Date: Thu, 27 Mar 2003 12:47:36 +0100 From: Peter Parnes Organization: LTU/CDT/Marratech X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] PSTN gateway Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Does anybody have any recommendations for a small and cheap SIP-PSTN gateway? /P --- Ps. I am Blogger! http://www.parnes.com/blog/ _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Thu Mar 27 07:32:24 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24929 for ; Thu, 27 Mar 2003 07:32:24 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2RCre013165 for sip-archive@odin.ietf.org; Thu, 27 Mar 2003 07:53:40 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2RCrAO13150; Thu, 27 Mar 2003 07:53:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2RCnlO13024 for ; Thu, 27 Mar 2003 07:49:47 -0500 Received: from mx1.kapsch.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24860 for ; Thu, 27 Mar 2003 07:27:59 -0500 (EST) Received: from dumbo.kapsch.co.at (dumbo.kapsch.co.at) by mx1.kapsch.net (Content Technologies SMTPRS 4.2.10) with ESMTP id ; Thu, 27 Mar 2003 13:30:20 +0100 Received: from atnews1.atc.co.at ([193.80.84.5]) by dumbo.kapsch.co.at with Microsoft SMTPSVC(5.0.2195.2966); Thu, 27 Mar 2003 13:30:20 +0100 Received: from aviepexs (aviepex3.atc.co.at [193.80.69.24]) Received: by aviepexs with Internet Mail Service (5.5.2653.19) id ; Thu, 27 Mar 2003 13:32:33 +0100 Message-ID: From: Tiefengraber Roland To: "'Peter Parnes'" , sip@ietf.org Subject: AW: [Sip] PSTN gateway Date: Thu, 27 Mar 2003 13:32:32 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-OriginalArrivalTime: 27 Mar 2003 12:30:20.0021 (UTC) FILETIME=[A14E0A50:01C2F45C] Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Hi you can take the Aphona StarLine SIP-PSTN Gateway StarLine 200 Basic 19inch Gateway: approx.2700 $ E1/LAN extension card (30 PRI channels): approx.2600 $ Up to 8 extension cards for each chassis Roland >Hi > >Does anybody have any recommendations for a small and cheap SIP-PSTN >gateway? _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Thu Mar 27 08:05:43 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27050 for ; Thu, 27 Mar 2003 08:05:42 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2RDQxB15695 for sip-archive@odin.ietf.org; Thu, 27 Mar 2003 08:26:59 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2RDQRO15609; Thu, 27 Mar 2003 08:26:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2RDMdO15360 for ; Thu, 27 Mar 2003 08:22:39 -0500 Received: from iere.net.avaya.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26299 for ; Thu, 27 Mar 2003 08:00:51 -0500 (EST) Received: from iere.net.avaya.com (localhost [127.0.0.1]) by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id h2RD0H020996 for ; Thu, 27 Mar 2003 08:00:17 -0500 (EST) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id h2RD0GM20986 for ; Thu, 27 Mar 2003 08:00:16 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sip] PSTN gateway Date: Thu, 27 Mar 2003 15:03:10 +0200 Message-ID: Thread-Topic: [Sip] PSTN gateway Thread-Index: AcL0YLFk6jBTsGhfSTqsCA85Vjb72gAAEizg From: "Romascanu, Dan (Dan)" To: "Tiefengraber Roland" , "Peter Parnes" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2RDMdO15361 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit I do not think that this type of questions and answers are appropriate for an IETF WG list. Dan > -----Original Message----- > From: Tiefengraber Roland [mailto:Roland.Tiefengraber@atc.co.at] > Sent: Thursday, March 27, 2003 2:33 PM > To: 'Peter Parnes'; sip@ietf.org > Subject: AW: [Sip] PSTN gateway > > > Hi > > you can take the ..... > > > > >Does anybody have any recommendations for a small and cheap SIP-PSTN > >gateway? _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Thu Mar 27 10:26:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03080 for ; Thu, 27 Mar 2003 10:26:35 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2RFlun25628 for sip-archive@odin.ietf.org; Thu, 27 Mar 2003 10:47:56 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2RFiHO25488; Thu, 27 Mar 2003 10:44:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2RFdjO25151 for ; Thu, 27 Mar 2003 10:39:45 -0500 Received: from dyn-tx-arch-crash.dfw.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02764; Thu, 27 Mar 2003 10:17:53 -0500 (EST) Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h2RFKB927303; Thu, 27 Mar 2003 09:20:11 -0600 From: Robert Sparks To: sip@ietf.org, sipping@ietf.org, impp@iastate.edu Content-Type: text/plain Message-Id: <1048778410.917.24.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 27 Mar 2003 09:20:11 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] [Fwd: [Simple] Call for availability: Interim meeting] Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit All - Ted Hardie (our new Apps Area AD) asked that I repeat this request on SIP, SIPPING, and IMPP. If you haven't already responded and plan to attend this SIMPLE WG interim meeting, please send a private message to me as soon as possible. RjS -----Forwarded Message----- > From: Robert Sparks > To: simple@ietf.org > Subject: [Simple] Call for availability: Interim meeting > Date: 26 Mar 2003 08:50:08 -0600 > > Folks - > > As mentioned at our meeting in IETF56 we are going to hold an > interim meeting between now and IETF57. We're planning > a two day session, but need to choose the actual dates. > Location will depend on the dates, but will probably be in > eastern Canada. > > If, and _only_ if, you are definitely planning to attend > please reply to me PRIVATELY by Friday with your availability > between May 12 and June 13. We'll find a date that accomodates as > many responders as possible. > > Thanks, > > RjS > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Thu Mar 27 14:03:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13078 for ; Thu, 27 Mar 2003 14:03:34 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2RJOxQ11726 for sip-archive@odin.ietf.org; Thu, 27 Mar 2003 14:24:59 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2RJH8O11250; Thu, 27 Mar 2003 14:17:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2RJ9HO10926 for ; Thu, 27 Mar 2003 14:09:17 -0500 Received: from sm.luth.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12042 for ; Thu, 27 Mar 2003 13:47:22 -0500 (EST) Received: from cdt.luth.se (blipp.cdt.luth.se [130.240.64.67]) by sm.luth.se (8.12.8/8.12.3) with ESMTP id h2RInaWm012625; Thu, 27 Mar 2003 19:49:36 +0100 (MET) Message-ID: <3E8347C7.909BED2F@cdt.luth.se> Date: Thu, 27 Mar 2003 19:49:43 +0100 From: Peter Parnes Organization: LTU/CDT/Marratech X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" CC: Tiefengraber Roland , sip@ietf.org Subject: Re: [Sip] PSTN gateway References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > I do not think that this type of questions and answers are appropriate > for an IETF WG list. Oh, I am very sorry that I misunderstood the purpose of this list. I thought discussing deployment and interoperability issues was under the IETF hat. Any suggestions on where such discussions should take place? /P --- Ps. I am Blogger! http://www.parnes.com/blog/ _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Thu Mar 27 14:14:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13531 for ; Thu, 27 Mar 2003 14:14:14 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2RJZck12225 for sip-archive@odin.ietf.org; Thu, 27 Mar 2003 14:35:38 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2RJYbO12188; Thu, 27 Mar 2003 14:34:37 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2RJTjO11917 for ; Thu, 27 Mar 2003 14:29:45 -0500 Received: from mailgate.pit.comms.marconi.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13284 for ; Thu, 27 Mar 2003 14:07:50 -0500 (EST) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA15934; Thu, 27 Mar 2003 14:09:35 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA22446; Thu, 27 Mar 2003 14:08:56 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Thu, 27 Mar 2003 14:08:56 -0500 Message-ID: <313680C9A886D511A06000204840E1CF030B5FAF@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'James Ford'" , sip@ietf.org Subject: RE: [Sip] The term UA Date: Thu, 27 Mar 2003 14:08:54 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , That depends on how the phone is implemented. The difference is pretty subtle, and may not matter to anyone. If you can't tell from the outside if there is more than one UA in the physical phone then I suppose the phone is the UA. I think most phones are implemented that way. Multiple users are just separate registrations with different AoRs. You could also say that there is a UA instance for each active call on a device if you want to. Brian > -----Original Message----- > From: James Ford [mailto:james_s_ford@hotmail.com] > Sent: Wednesday, March 26, 2003 8:53 AM > To: sip@ietf.org > Subject: [Sip] The term UA > > > > Hi, > When a single phone is used by several users, do we refer to each user > as a seperate UA or do we refer to the phone as the UA? > Thanks, > James. > > > > > _________________________________________________________________ > Help STOP SPAM with the new MSN 8 and get 2 months FREE* > http://join.msn.com/?page=features/junkmail > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Fri Mar 28 06:52:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25004 for ; Fri, 28 Mar 2003 06:52:59 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2SCEhn30435 for sip-archive@odin.ietf.org; Fri, 28 Mar 2003 07:14:43 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2SCE7O30400; Fri, 28 Mar 2003 07:14:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2SC7IO29897 for ; Fri, 28 Mar 2003 07:07:18 -0500 Received: from fox.iptel.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24904 for ; Fri, 28 Mar 2003 06:45:03 -0500 (EST) Received: by fox.iptel.org (Postfix, from userid 534) id A0843214; Fri, 28 Mar 2003 12:47:22 +0100 (CET) Received: from jku07.iptel.org (port-212-202-201-178.reverse.qdsl-home.de [212.202.201.178]) by fox.iptel.org (Postfix) with ESMTP id D333B1FA; Fri, 28 Mar 2003 12:47:21 +0100 (CET) Message-Id: <5.2.0.9.0.20030328123135.027c0b98@mailhost.fokus.gmd.de> X-Sender: jiri@iptel.org (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 28 Mar 2003 12:38:31 +0100 To: Harald Tveit Alvestrand From: Jiri Kuthan Subject: Re: [Sip] Eating our own Dog Food...could the IAB and IESG use SIP for conference calls Cc: sip@ietf.org In-Reply-To: <711640000.1048619617@askvoll.hjemme.alvestrand.no> References: <5.2.0.9.2.20030324185638.016696c8@popd.ix.netcom.com> <5.2.0.9.2.20030324185638.016696c8@popd.ix.netcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Status: No, hits=-17.2 required=5.0 tests=AWL,EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES, REPLY_WITH_QUOTES autolearn=ham version=2.51 X-Spam-Checker-Version: SpamAssassin 2.51 (1.174.2.5-2003-03-20-exp) Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , At 08:13 PM 3/25/2003, Harald Tveit Alvestrand wrote: >A "normal" teleconference provider that *also* allows SIP dialin over the Internet would probably be perfect. If you have one - send email to me - PRIVATELY - and I will forward to the relevant parties at the secretariat. As said, we can provide tech-support or hosting a SIP server (iptel.org/ser) -- the server itself is free. I think I could get a conferencing server from a partner of ours. The missing piece then is PSTN connectivity, both dial-in for out-of-IP callers and callees. We can't unfortunately afford sponsoring that -- we are non-profit (on purpose ;)). Maybe approaching companies like deltathree would make sense? -Jiri _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Fri Mar 28 15:13:17 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16764 for ; Fri, 28 Mar 2003 15:13:17 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2SKZBF04053 for sip-archive@odin.ietf.org; Fri, 28 Mar 2003 15:35:11 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2SKYNO03987; Fri, 28 Mar 2003 15:34:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2SKPTO03516 for ; Fri, 28 Mar 2003 15:25:29 -0500 Received: from mail.aastra.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15264 for ; Fri, 28 Mar 2003 15:02:58 -0500 (EST) Received: by mail.aastra.com with Internet Mail Service (5.5.2653.19) id ; Fri, 28 Mar 2003 14:54:05 -0500 Message-ID: From: Vijay Gaur To: sip@ietf.org Date: Fri, 28 Mar 2003 14:53:56 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] SIP Client Transaction Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Hi, RFC 3261 section "17.1.1.1 Overview of INVITE Transaction" specifies the state machine for Client INVITE transaction. In the diagram if client transaction state comes to proceeding after receiving 1xx message, no timers are started. It is not specified that if no message is received further in this state, how this transaction will be terminated. There is no timer specified to clear this transaction. Do we need to start timer B again in this state and clear the transaction after timer B expiry? Your feedback is appreciated. Thanks, Vijay _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Fri Mar 28 17:30:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22115 for ; Fri, 28 Mar 2003 17:30:50 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2SMqn414749 for sip-archive@odin.ietf.org; Fri, 28 Mar 2003 17:52:49 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2SMq6O14719; Fri, 28 Mar 2003 17:52:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P5rgO03983 for ; Tue, 25 Mar 2003 00:53:42 -0500 Received: from bharatmail.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18899 for ; Tue, 25 Mar 2003 00:33:01 -0500 (EST) Received: from server1.bharatmart.com (ensim.rackshack.net [207.44.196.29]) by bharatmail.com (8.11.6/8.11.6) with ESMTP id h2P82X713030 for sip@ietf.org; Tue, 25 Mar 2003 02:02:34 -0600 Message-Id: <200303250802.h2P82X713030@bharatmail.com> Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: binary MIME-Version: 1.0 X-Mailer: MIME-tools 5.411 (Entity 5.404) From: murali To: sip@ietf.org Date: Tue Mar 25 11:05:20 2003 Content-Transfer-Encoding: binary Subject: [Sip] how do you segregate host from token? Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: binary Hi, In the field generic-param, its mentioned that generic-param = token[EQUAL gen-value} now gen-value = token/host/quoted-string. If host is an IPV4 address or IPV6 address, its fine. But, if host is a hostname which in turn is defined as hostname = *(domainlabel".")toplabel [.] token also has the same allowable characters as allowed in domainname. So, if I am writing a parser for gen-value, when do I recognize it as a token and when do I recognise it as a host with a hostname which comprises of a domainlabel followed by a toplabel? Is there any particular character or pattern which distinguishes the hostname from the token? Regards Murali. ------- Murali Voleti, #503,Maheswari complex, Masab Tank, Hyderabad Tele:(040) 6502272 ext:211 _____________________________________________________________ Get Your Free ScanMail and Email At http://mail.ttkbharatplanet.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Fri Mar 28 17:34:54 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22222 for ; Fri, 28 Mar 2003 17:34:54 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2SMuqF14877 for sip-archive@odin.ietf.org; Fri, 28 Mar 2003 17:56:52 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2SMuQO14864; Fri, 28 Mar 2003 17:56:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PGl0O24754 for ; Tue, 25 Mar 2003 11:47:00 -0500 Received: from heimdall.skotos.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20238; Tue, 25 Mar 2003 11:26:06 -0500 (EST) Received: from artemis (unknown [198.232.133.248]) by heimdall.skotos.net (Postfix) with SMTP id 7FA86168030; Tue, 25 Mar 2003 08:28:24 -0800 (PST) Message-ID: <209301c2f2eb$d9a99080$f885e8c6@artemis> From: "Christopher Allen" To: , "Richard Shockey" Cc: , "Bill Woodcock" References: <5.2.0.9.2.20030324185638.016696c8@popd.ix.netcom.com> Date: Tue, 25 Mar 2003 08:30:30 -0800 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 Content-Transfer-Encoding: 7bit Subject: [Sip] Re: Eating our own Dog Food...could the IAB and IESG use SIP for conference calls Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Richard Shockey wrote: > Like many of us I was moved my Harald's appeal for suggestions for > helping to cut down costs in the IETF. > > I certainly endorse the idea of considering Canada or Mexico as > possible sites for future IETF meetings, but I suspect that the > weekly teleconferece calls that the IAB and IESG have represent a > significant line item for the Secretariat. > > In case anyone has not heard, SIP is quite capable of handling this > type of task and there are a variety of commercial as well as open > source Client User Agents as well as commercial products and services > that could help reduce this cost. > > I'm sure the SIP working group could help the Secretariat identify > products and services that could make this essential function more > productive and operate at less cost. Bill Woodock of Packet Clearing House has set up a SIP network where you dial an ASN (and optionally an extension) that will ring various NOCs. Currently they are using Cisco phones, but there is no reason why software SIP based phones shouldn't work as well. http://www.pch.net/inoc-dba/ ~-~ INTER-NOC HOTLINE PHONE SYSTEM Packet Clearing House operates the Inter-Network Operations Center Dial-By-ASN (INOC-DBA) hotline phone system, a global voice telephony network that connects the network operations centers and security incident response teams of critical Internet infrastructure providers such as backbone carriers, Internet service providers, and Internet exchanges as well as critical individuals within the policy, regulatory, Internet governance, security and vendor communities. The INOC-DBA is a closed system, ensuring secure and authenticated communications, and uses a combination of highly redundant directory services and direct peer-to-peer communications between stations to create a resilient, high-survivability network. It carries both routine operational traffic and emergency-response traffic. ~-~ It may make sense to have the IESG members to have access to this emergency network in general, besides for its use in IESG business. I don't believe at this point that they have conferencing services available, only point-to-point calls, but I'm fairly certain from some discussions that I've had with some SIP conferencing tool vendors that we should be able to get them to donate those services as well. We might even be able to get Cisco to donate some phones. -- Christopher Allen ---------------------------------------------------------------------- .. Christopher Allen Alacrity Management .. .. 1563 Solano Ave. #353 .. .. o510/649-4030 f510/649-4034 Berkeley, CA 94707 .. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Fri Mar 28 17:39:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22380 for ; Fri, 28 Mar 2003 17:39:13 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2SN1C215020 for sip-archive@odin.ietf.org; Fri, 28 Mar 2003 18:01:12 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2SN0jO14995; Fri, 28 Mar 2003 18:00:45 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PGqTO25020 for ; Tue, 25 Mar 2003 11:52:29 -0500 Received: from paixhost.pch.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20483; Tue, 25 Mar 2003 11:31:36 -0500 (EST) Received: from ns1.pch.net (ns1.pch.net [206.220.231.1]) by paixhost.pch.net (8.11.6/8.11.6) with ESMTP id h2PGXUR00958; Tue, 25 Mar 2003 08:33:30 -0800 (PST) Date: Tue, 25 Mar 2003 08:33:30 -0800 (PST) From: Bill Woodcock To: Christopher Allen cc: ietf@ietf.org, Richard Shockey , In-Reply-To: <209301c2f2eb$d9a99080$f885e8c6@artemis> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Sip] Re: Eating our own Dog Food...could the IAB and IESG use SIP for conference calls Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , > Currently they are using Cisco phones, but there is no reason why software SIP > based phones shouldn't work as well. Actually, only about three-quarters of the phones are Ciscos, to the best of my knowledge; meaning that there are more than a hundred non-Cisco (mostly open-source software) phones on the network as well. A lot of the IAB and IESG folks are already on the INOC network. Should we put some effort into getting the remainder (and newly-appointed) folks on as well? -Bill _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Fri Mar 28 17:43:33 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22496 for ; Fri, 28 Mar 2003 17:43:33 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2SN5Vs15160 for sip-archive@odin.ietf.org; Fri, 28 Mar 2003 18:05:31 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2SN58O15153; Fri, 28 Mar 2003 18:05:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PHniO29705 for ; Tue, 25 Mar 2003 12:49:44 -0500 Received: from mail2.edial.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22368; Tue, 25 Mar 2003 12:28:49 -0500 (EST) Received: from petrack8200 (test2.edial.com [63.175.28.132]) by mail2.edial.com (8.11.6/8.11.6) with ESMTP id h2PHV3Z15468; Tue, 25 Mar 2003 12:31:03 -0500 From: "Scott Petrack" To: "'Henry Sinnreich'" , "'Richard Shockey'" , Cc: , "Scott Petrack" , "'Christian Stredicke'" , "Ben Teitelbaum" Subject: RE: [Sip] Eating our own Dog Food...could the IAB and IESG use SIP for conference calls Date: Tue, 25 Mar 2003 12:31:05 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit eDial can definitely help here, and in the longer term perhaps Internet2 can help: 1. I just made a URL and a dial-in access code for a reservationless conference which can be dialed in from a PSTN phone or directly from a SIP phone. (The URL allows people to join the conference call without punching in any access codes). Since Henry's letter went out to two very large mailing lists, I'll just ask for the duly authorized person who cares about IAB and IESG conferences to give me a call or write me and I'll give you the info. 2. Internet2 recently bought an eDial server and I imagine that as part of their charter they can help the IAB/IESG with these sorts of services. I have cc-ed Ben Teitelbaum of internet2.edu on this letter. I could provide some conferencing in the short term, but that Internet2 would be a very appropriate way to host such conferences going forward. Since the eDial boxes do mixed SIP and PSTN conferences, it might make for a smooth transition for people who don't believe in VoIP.....(I remember Steve Deering once ranting at me about this). Scott Scott Petrack, CTO eDial, Inc. mobile: +1-617-592-8688 email: scott.petrack@edial.com IM: scott.petrack@edial.com (MSN) and sbpetrack (AOL) find me: http://beta.edial.com/call/scott.petrack > -----Original Message----- > From: Henry Sinnreich [mailto:Henry.Sinnreich@wcom.com] > Sent: Tuesday, March 25, 2003 9:46 AM > To: 'Richard Shockey'; ietf@ietf.org > Cc: sip@ietf.org; Scott Petrack; Christian Stredicke > Subject: RE: [Sip] Eating our own Dog Food...could the IAB and IESG use > SIP for conference calls > > There are excellent SIP voice conferencing bridges available, such as > from snom AG and eDial. They can be used with various soft clients such > as the Windows Messenger, HotSIP Active Contacts or the Pingtel instant > expressa, or any SIP phone. > > I have taken the liberty of copying here the contacts for snom AG and > eDial, in case this will be pursued. I wonder if snom AG or eDial would > just give the IESG and IAB access to their conference servers? > > Would there be interest to have access to a WorldCom SIP conference > bridge? > > Thanks, Henry > > > -----Original Message----- > > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On > > Behalf Of Richard Shockey > > Sent: Monday, March 24, 2003 6:04 PM > > To: ietf@ietf.org > > Cc: sip@ietf.org > > Subject: [Sip] Eating our own Dog Food...could the IAB and > > IESG use SIP for conference calls > > > > > > > > Like many of us I was moved my Harald's appeal for > > suggestions for helping > > to cut down costs in the IETF. > > > > I certainly endorse the idea of considering Canada or Mexico > > as possible > > sites for future IETF meetings, but I suspect that the weekly > > teleconferece > > calls that the IAB and IESG have represent a significant line > > item for the > > Secretariat. > > > > In case anyone has not heard, SIP is quite capable of > > handling this type of > > task and there are a variety of commercial as well as open > > source Client > > User Agents as well as commercial products and services that > > could help > > reduce this cost. > > > > I'm sure the SIP working group could help the Secretariat > > identify products > > and services that could make this essential function more > > productive and > > operate at less cost. > > > > > > > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > > Richard Shockey, Senior Manager, Strategic Technology > > Initiatives NeuStar Inc. > > 46000 Center Oak Plaza - Sterling, VA 20166 > > Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 > > 815.333.1237 > or > > > > ; > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip Use > sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Fri Mar 28 17:48:47 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22638 for ; Fri, 28 Mar 2003 17:48:47 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2SNAkh16118 for sip-archive@odin.ietf.org; Fri, 28 Mar 2003 18:10:46 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2SNAQO16099; Fri, 28 Mar 2003 18:10:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PHuPO29911 for ; Tue, 25 Mar 2003 12:56:25 -0500 Received: from mxout2.cac.washington.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22526; Tue, 25 Mar 2003 12:35:29 -0500 (EST) Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout2.cac.washington.edu (8.12.1+UW03.03/8.12.1+UW02.12) with ESMTP id h2PHbiva016573; Tue, 25 Mar 2003 09:37:44 -0800 Received: from D-128-208-110-217.dhcp4.washington.edu (D-128-208-110-217.dhcp4.washington.edu [128.208.110.217]) (authenticated bits=0) by smtp.washington.edu (8.12.1+UW03.03/8.12.1+UW02.12) with ESMTP id h2PHbhwb027222 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Tue, 25 Mar 2003 09:37:43 -0800 Date: Tue, 25 Mar 2003 09:37:00 -0800 (PST) From: "RL 'Bob' Morgan" X-X-Sender: rlmorgan@localhost.localdomain To: Richard Shockey cc: ietf@ietf.org, In-Reply-To: <5.2.0.9.2.20030324185638.016696c8@popd.ix.netcom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Sip] Re: Eating our own Dog Food...could the IAB and IESG use SIP for conference calls Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , On Mon, 24 Mar 2003, Richard Shockey wrote: > I certainly endorse the idea of considering Canada or Mexico as possible > sites for future IETF meetings, but I suspect that the weekly > teleconferece calls that the IAB and IESG have represent a significant > line item for the Secretariat. > > In case anyone has not heard, SIP is quite capable of handling this type > of task and there are a variety of commercial as well as open source > Client User Agents as well as commercial products and services that > could help reduce this cost. Are there existence proofs of IETF-style WGs conferencing via SIP these days? I don't know anything about these services, but it seems to me that to be practical, a SIP-capable conf call service would also have to support plain-old telephony callers as well. - RL "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 mailnull@www1.ietf.org Fri Mar 28 17:52:55 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22823 for ; Fri, 28 Mar 2003 17:52:55 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2SNEsF16321 for sip-archive@odin.ietf.org; Fri, 28 Mar 2003 18:14:54 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2SNEDO16299; Fri, 28 Mar 2003 18:14:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PKPJO09561 for ; Tue, 25 Mar 2003 15:25:19 -0500 Received: from dyn-tx-arch-crash.dfw.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28995 for ; Tue, 25 Mar 2003 15:04:20 -0500 (EST) Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h2PK6c923067 for ; Tue, 25 Mar 2003 14:06:38 -0600 From: Robert Sparks To: sip@ietf.org Content-Type: multipart/mixed; boundary="=-Kw37/HfBI5hw03WNxTHW" Message-Id: <1048622792.997.80.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 25 Mar 2003 14:06:32 -0600 Subject: [Sip] Non-Invite adhoc minutes and action plan Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , --=-Kw37/HfBI5hw03WNxTHW Content-Type: text/plain Content-Transfer-Encoding: 7bit Here are the minutes from the ad-hoc we held last Tuesday on the Non-Invite problem. Many thanks to Cullen Jennings for being the minute taker. I will be taking the output of this discussion and revising the non-invite draft reflecting the following input: - Separate the analysis of problems due to slow responding elements from the analysis of problems due to non-responding elements. - Explore mechanisms to let the next hop better estimate how much time it has to complete. If you have other input to contribute after you look over these notes, please send it to the list soon. I will begin revising the non-invite draft within the week. Thanks to everyone for the thought they've put into this so far. RjS --=-Kw37/HfBI5hw03WNxTHW Content-Disposition: attachment; filename=NonInviteNotes.txt Content-Type: text/plain; name=NonInviteNotes.txt; charset=UTF-8 Content-Transfer-Encoding: 7bit Folks: Adam Roach; Ben Campbell; Cullen Jennings; Daniel Petrie; Dean Willis; Gonzalo Camarillo; Jonathan Rosenberg; Robert Sparks Conclusion : Identified we need to tear this apart addressing the problem of having to take a long time to generate a response separately from the problem of something that was going to respond went away. Summary: The "Random Notes" below are the stuff I typed in the meeting. Right here I am going to describe what I took out of the meeting - this could be a totally warped impression of what happened - I was pretty tired. So read the random notes too and make your own summary. The problem we are trying to solve is how to clean up state on all the elements. The major two cases we need to deal with are 1) something died and will never respond 2) something is taking a long time to respond. Case 2 splits into two sub cases. The first 2a where it is a automata that is holding up the response and 2b where something is waiting for input from a human before responding. Some things to keep in mind when evaluating solutions are: systems use different values of T1. DNS SRV failures complicate things. A similar problem might be able to happen in INVITE transactions where things fork or CANCEL. We brainstormed a few possible approaches to this problem. - Set an expire time of some sort on the transaction o If this is absolute, then need synchronized time - Yuck o If we ignore the network time (the hops) and only count the processing time at each node (the hipitty) then absolute time would not be needed o Make the time start at 64*T1 for the first node and shrink as the message traverses nodes o won't work - Make the time at each node be large enough (i.e. current max hops * 64 * T1) that downstream nodes will timeout first. o 64*T1*70 = 37 minutes * 1000 transaction per second is a lot of state - Have any transaction that is going to take awhile, return some code that more or less amounts to try back later with the same request and I will give you the answer then. o Not clear how this work when nodes fail instead of just being slow The reason I came to the meeting was to say that no node should have to hold state forever and that it is reasonable to put some upper bound on how long things are allowed to take and still be a single transaction. I don't think the problem is solvable without this constraint. Random Notes: First question - should we kill proposal B? Considered how HTTP deals with the problem. Feeling was HTTP did not deal with it yet but would need to in the future with SOAP. Decided that right now we don't have enough information to kill proposal B - need to brainstorm some options. Jonathan posed the problem as: Imagine the timeout is very long then figure out how to clean up state. There is state in user agent, proxies. Idea: allow the proxy to go stateless at some point. Consider invite stuff. Proxy may have to maintain state arbitrarily long. Solution was to have uas send provisional to refresh timers. Not sure this was true. If we make things arbitrarily long, how deal with crashed things... The ideas of shrinking the timer: The uac will have timer 70*64*t1. Each proxy have max hops * 64 * t1. uas has timer 64 *t1 or could possibly max hops *54 *t1. This results in keeping state 37 minutes - all agree 37 minutes does not sound good. Invite has this same problem if the cancel fails you can get this cascaded. Really two problem here - one is failure - other is device is just slow doing it's backend processing or something. Important point - not all systems have t1 at 500 ms - this can mess up things and we have to take it into account. The DNS SRV fail over needs to be considered. Disused the idea of saying you have this much time to process this message. It can get decremented along the way. Is the whole discussion purely that the timer number is too low. If we want to deal with human interaction, then it is a different problem that time for automata to respond. If the UAS timer is large enough, then the only time that there is no response is when something failed. One proposal is make timer bigger than t1*64 and then toss out the 408 somehow. Do we let the client continues to allow the transaction to processed using some sort of message back or do we redo the request at some future time when the far side as completed the answer? --=-Kw37/HfBI5hw03WNxTHW Content-Disposition: attachment; filename=NonInviteNotes.pdf Content-Type: application/pdf; name=NonInviteNotes.pdf Content-Transfer-Encoding: base64 JVBERi0xLjMNJeLjz9MNCjMyIDAgb2JqDTw8IA0vTGluZWFyaXplZCAxIA0vTyAzNCANL0ggWyA4 NzQgMjgzIF0gDS9MIDQ1Nzc3IA0vRSAzODIzNSANL04gMyANL1QgNDUwMTkgDT4+IA1lbmRvYmoN ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICB4cmVmDTMyIDIyIA0wMDAwMDAwMDE2IDAwMDAwIG4NCjAwMDAwMDA3ODcgMDAwMDAgbg0KMDAw MDAwMTE1NyAwMDAwMCBuDQowMDAwMDAxMzI1IDAwMDAwIG4NCjAwMDAwMDE0NjEgMDAwMDAgbg0K MDAwMDAwMTY4NSAwMDAwMCBuDQowMDAwMDAyNDY4IDAwMDAwIG4NCjAwMDAwMDI2ODggMDAwMDAg bg0KMDAwMDAwMzM3OSAwMDAwMCBuDQowMDAwMDA2MDI4IDAwMDAwIG4NCjAwMDAwMDYyNTQgMDAw MDAgbg0KMDAwMDAwNjMzMCAwMDAwMCBuDQowMDAwMDA2Njc2IDAwMDAwIG4NCjAwMDAwMDc0NjEg MDAwMDAgbg0KMDAwMDAwNzcwMiAwMDAwMCBuDQowMDAwMDA3ODkxIDAwMDAwIG4NCjAwMDAwMDgx ODMgMDAwMDAgbg0KMDAwMDAwODI0NiAwMDAwMCBuDQowMDAwMDIzMDA1IDAwMDAwIG4NCjAwMDAw Mzc2NTYgMDAwMDAgbg0KMDAwMDAwMDg3NCAwMDAwMCBuDQowMDAwMDAxMTM2IDAwMDAwIG4NCnRy YWlsZXINPDwNL1NpemUgNTQNL0luZm8gMzEgMCBSIA0vUm9vdCAzMyAwIFIgDS9QcmV2IDQ1MDA5 IA0vSURbPGZhMjFjNzdkNDE2MjY3OTUzMGJlYWM2ZDQxZTI1ZDYzPjxmYTIxYzc3ZDQxNjI2Nzk1 MzBiZWFjNmQ0MWUyNWQ2Mz5dDT4+DXN0YXJ0eHJlZg0wDSUlRU9GDSAgICAgDTMzIDAgb2JqDTw8 IA0vVHlwZSAvQ2F0YWxvZyANL1BhZ2VzIDE5IDAgUiANL0pUIDMwIDAgUiANL1BhZ2VMYWJlbHMg MTggMCBSIA0+PiANZW5kb2JqDTUyIDAgb2JqDTw8IC9TIDgzIC9UIDE0NCAvTCAxODkgL0ZpbHRl ciAvRmxhdGVEZWNvZGUgL0xlbmd0aCA1MyAwIFIgPj4gDXN0cmVhbQ0KSIliYGBgBqIsBlYgmcgg wIAAAgwsQFEWBo4Khp7zbPYMDD8c4HIsGkvMD15SvsPA4OLi4tHRwMDQ0cDRAFEGBOwMDAtmA2kh IBYGi9gz8DEuYZmg4XSBqUTdqa1hMYOJ4IYtDZsYf/AFMFhmPP4g+mBzA8RsDgaGxSsYwO5iYGDk A/EZmMAyfAwMK5IhMkxdT9eAhAQZGFa9hSrwBggwAF/iI14NZW5kc3RyZWFtDWVuZG9iag01MyAw IG9iag0xNjQgDWVuZG9iag0zNCAwIG9iag08PCANL1R5cGUgL1BhZ2UgDS9QYXJlbnQgMTkgMCBS IA0vUmVzb3VyY2VzIDM1IDAgUiANL0NvbnRlbnRzIDQwIDAgUiANL1RodW1iIDggMCBSIA0vTWVk aWFCb3ggWyAwIDAgNjEyIDc5MiBdIA0vQ3JvcEJveCBbIDAgMCA2MTIgNzkyIF0gDS9Sb3RhdGUg MCANPj4gDWVuZG9iag0zNSAwIG9iag08PCANL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gDS9Gb250 IDw8IC9GMiAzOSAwIFIgL0YzIDM3IDAgUiAvRjQgNDYgMCBSIC9GNSA0NCAwIFIgPj4gDS9FeHRH U3RhdGUgPDwgL0dTMSA0OCAwIFIgPj4gDT4+IA1lbmRvYmoNMzYgMCBvYmoNPDwgDS9UeXBlIC9G b250RGVzY3JpcHRvciANL0FzY2VudCA2OTkgDS9DYXBIZWlnaHQgNjc2IA0vRGVzY2VudCAtMjA1 IA0vRmxhZ3MgMjYyMTc4IA0vRm9udEJCb3ggWyAtMTY4IC0yMTggMTAwMCA5MzUgXSANL0ZvbnRO YW1lIC9UaW1lcy1Cb2xkIA0vSXRhbGljQW5nbGUgMCANL1N0ZW1WIDEzOSANL1hIZWlnaHQgNDYx IA0vRm9udEZpbGUzIDUwIDAgUiANPj4gDWVuZG9iag0zNyAwIG9iag08PCANL1R5cGUgL0ZvbnQg DS9TdWJ0eXBlIC9UeXBlMSANL0ZpcnN0Q2hhciAzMiANL0xhc3RDaGFyIDE4MSANL1dpZHRocyBb IDI1MCAzMzMgNTU1IDUwMCA1MDAgMTAwMCA4MzMgMjc4IDMzMyAzMzMgNTAwIDU3MCAyNTAgMzMz IDI1MCAyNzggDTUwMCA1MDAgNTAwIDUwMCA1MDAgNTAwIDUwMCA1MDAgNTAwIDUwMCAzMzMgMzMz IDU3MCA1NzAgNTcwIDUwMCANOTMwIDcyMiA2NjcgNzIyIDcyMiA2NjcgNjExIDc3OCA3NzggMzg5 IDUwMCA3NzggNjY3IDk0NCA3MjIgNzc4IA02MTEgNzc4IDcyMiA1NTYgNjY3IDcyMiA3MjIgMTAw MCA3MjIgNzIyIDY2NyAzMzMgMjc4IDMzMyA1ODEgNTAwIA0zMzMgNTAwIDU1NiA0NDQgNTU2IDQ0 NCAzMzMgNTAwIDU1NiAyNzggMzMzIDU1NiAyNzggODMzIDU1NiA1MDAgDTU1NiA1NTYgNDQ0IDM4 OSAzMzMgNTU2IDUwMCA3MjIgNTAwIDUwMCA0NDQgMzk0IDIyMCAzOTQgNTIwIDI1MCANMjUwIDI1 MCAyNTAgMjUwIDI1MCAyNTAgMjUwIDI1MCAyNTAgMjUwIDI1MCAyNTAgMjUwIDI1MCAyNTAgMjUw IA0yNTAgMjUwIDI1MCAyNTAgMjUwIDI1MCAyNTAgMjUwIDI1MCAyNTAgMjUwIDI1MCAyNTAgMjUw IDI1MCAyNTAgDTI1MCAyNTAgNTAwIDUwMCAyNTAgMjUwIDI1MCAyNTAgMjUwIDc0NyAyNTAgMjUw IDI1MCAyNTAgMjUwIDI1MCANMjUwIDU3MCAyNTAgMjUwIDI1MCA1NTYgXSANL0VuY29kaW5nIC9X aW5BbnNpRW5jb2RpbmcgDS9CYXNlRm9udCAvVGltZXMtQm9sZCANL0ZvbnREZXNjcmlwdG9yIDM2 IDAgUiANPj4gDWVuZG9iag0zOCAwIG9iag08PCANL1R5cGUgL0ZvbnREZXNjcmlwdG9yIA0vQXNj ZW50IDY5OSANL0NhcEhlaWdodCA2NjIgDS9EZXNjZW50IC0yMTcgDS9GbGFncyAzNCANL0ZvbnRC Qm94IFsgLTE2OCAtMjE4IDEwMDAgODk4IF0gDS9Gb250TmFtZSAvVGltZXMtUm9tYW4gDS9JdGFs aWNBbmdsZSAwIA0vU3RlbVYgODQgDS9YSGVpZ2h0IDQ1MCANL0ZvbnRGaWxlMyA0OSAwIFIgDT4+ IA1lbmRvYmoNMzkgMCBvYmoNPDwgDS9UeXBlIC9Gb250IA0vU3VidHlwZSAvVHlwZTEgDS9GaXJz dENoYXIgMzIgDS9MYXN0Q2hhciAxODEgDS9XaWR0aHMgWyAyNTAgMzMzIDQwOCA1MDAgNTAwIDgz MyA3NzggMTgwIDMzMyAzMzMgNTAwIDU2NCAyNTAgMzMzIDI1MCAyNzggNTAwIA01MDAgNTAwIDUw MCA1MDAgNTAwIDUwMCA1MDAgNTAwIDUwMCAyNzggMjc4IDU2NCA1NjQgNTY0IDQ0NCA5MjEgDTcy MiA2NjcgNjY3IDcyMiA2MTEgNTU2IDcyMiA3MjIgMzMzIDM4OSA3MjIgNjExIDg4OSA3MjIgNzIy IDU1NiANNzIyIDY2NyA1NTYgNjExIDcyMiA3MjIgOTQ0IDcyMiA3MjIgNjExIDMzMyAyNzggMzMz IDQ2OSA1MDAgMzMzIA00NDQgNTAwIDQ0NCA1MDAgNDQ0IDMzMyA1MDAgNTAwIDI3OCAyNzggNTAw IDI3OCA3NzggNTAwIDUwMCA1MDAgDTUwMCAzMzMgMzg5IDI3OCA1MDAgNTAwIDcyMiA1MDAgNTAw IDQ0NCA0ODAgMjAwIDQ4MCA1NDEgMCAwIDAgMCANMCAwIDEwMDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMzMzIDAgMCAwIDUwMCAwIDAgMCAwIDAgMCAwIDAgMCANMjUwIDAgNTAwIDUwMCAwIDAg MCAwIDAgNzYwIDAgMCAwIDMzMyAwIDAgMCA1NjQgMCAwIDAgNTAwIF0gDS9FbmNvZGluZyAvV2lu QW5zaUVuY29kaW5nIA0vQmFzZUZvbnQgL1RpbWVzLVJvbWFuIA0vRm9udERlc2NyaXB0b3IgMzgg MCBSIA0+PiANZW5kb2JqDTQwIDAgb2JqDTw8IC9MZW5ndGggMjU3NCAvRmlsdGVyIC9GbGF0ZURl Y29kZSA+PiANc3RyZWFtDQpIibxX2Y7byBVF8thfUcgTaYxkkdpaNvLg8TLJIDECtzCDwM5DtUg1 aZEshUU2Z+Yz8sU5dylR6rY9NhAEAihW8datu5y7fb+9evomNYnZ7q+S1Mzww99mNp0t06VZzzbT ZIaXbX01M3dXT3+4Scydx/t2R4/hKjLx9iNYzIXFzEySabI221dXE/BIEiJ8H71x8SRJogrPeXTA cxl5PNPoWTy5Bot/bX8cxRAec+IBFjN62zE3fh3A7kVm4+V0HtUxtteReedkveNnESd4Pjff57xs zEulPuIykN/KflU9Ny/7qgpUcTKLfownG1DoVlM2d3FCzPxz88o2pR7UW/8hy67VfdDIi1zXsBjm 57KqSpwn9j+45jd7zsOJ6qLxkjR+HwVp5a/FcffcqGCukd2uuLjjnfNgjzcVXDVsVfrnIAhbnbk5 Kud4gefBiwjbJ1/lVPLCbHFyCL2C/KVrdlXvS9eYZ3r0076crcajK/HlX+NkPl1FGSm4gAILLJp4 hmdX7ktZZ2aQF9Ock+lHJjadM11ueaeNJysQma4ovZGtIxOFz3Rhp1+yrBU+3pfK/Y6MSSwLvRVQ nUXH1t1WsgHcJXSB25tCuNw/Ogtx5NPhXGS91FTuIX1Zh8seIGIyGu7cbrjgLhbGczwbkpFtQqvW drlIbQ2ssT598EfX+Nz4nEwEs1iiBBjTFKtf44QYmr2caOMUK1eTHYxqz6egPpGT+t7VOczciCig tJ0ZrJe7ZdMR1FdRGSQMpO4EvPdRm5Ng5OaG/MK3DDHZGItkNco2Neab8bqQHHTT1/EasidrwgG0 uwbTyQopaP2FDCTWX5+svxbrb2GSP8VrBNC7eDJHZNomg6Xeuo7SGqeQOeUNoTG3rHvYrZTGSRIY jG1zNrLveiXc78WEiI6UGHTsorWYYR4d88yUyqXRdEQM6jzvxBnzaBqSYyCU7UK2O1PkjAwSCvZe R+HClC8U8NRGDqmk6sPA6uTDi/yV5X7Xlre5GQqlBiYulXHuYFzfEYBGqS9ZTyR6d64P1soMeFoc 7mwV9tQcwn6w7THYGeapj0AV5yRcM0JtIIgW9njML0Mmw5WjlADoQNWCcgbHDQJA46gTF4/h0pVt nk3NjTuFms1YL13aiwAlmDSuyz2ZwQA2prYHDVbl6JS0b014lWBoRuwDi+lYGFMtjL6vUTdWlN1/ FUdOPx8v2JKqugnopreAbg54wvYmymv5R3gqLgivVMuxCSWTa/zjvutpEpVCStom+L+LaZOIaZe0 IT7eKed72ciNHvOUWUBQuOHhmV0Qhoy6gVFTMA7XmP6I4BECq/+5geutntK/wLQI9+YPVFTujXzv LqSaGrJLsKYkhutTYrgW09X2o2tNNzizsz7XRAi7NXmesS+vOWyy3FZmKLuCYz/RLx9iaJVGF1kV y6wEngkpwgwdAdjd562sQ+5MP8QPhEtOwiUKjzO+MAbiq7OH01LrBZcmiJNEuk+liWTWi6bopzzb PeHQAUWqB4w/VmXnTdlQ+YMNfH8rdhDb7cvWdya1FzD+RE8waOGVSq11sezMqZzrXy99gqtl2bFU Cy3zVIxO2xSnOF24KuOmjmsuQHMq8aEJODqpy9KC+IuqTUa+RVrLlZj9JFcUcmrkjcsGOVV24+7v gGcP6JTNEZlx3yJNWFP0tW20elyztVMiyi88r6nzOhK4fDni+brNaHGN+BvRZMNNk4jLuGevwpkH +SpPaqYIPo2pSyrahWw3si2Le15YfqdsDT69rDpplZJIb6Fs0MtOh2wtLt6w78OFz4SB8Yoz5BqW r5PPtXz2pveqRFbu9/kjNiJgZ+7lNhWul49B2Qtojhl2phkWtWSbTM2rtzfm5t1PZm+5iy6rnjEx j7xWILPjpYtnPHlUpayFnBG5juTEaPG5CLGGC18YXzKa0bGUlZxqzakFnYvOuKYu9WjRoT4KQxuI yHOFHEa94//mrBTCgaHmU4V6K+XqJ/njvnwRbV+brrWNJy6LaMdPcZMkI/b9gs0sPa703ezilbh4 IWoB/oDuwTj5JCfMyxdy3duXr6Xe/i1OE2n0fq9uPe7KfpZORrosc9vasvGda2tKn9LVho+DCa2C tjboFGA1g76gdXYXOheu0tKJiO3rINfTNwvpFZPpkrqfVGacUdQ//PFiECKy2WkMWo+4UtFvyHZr nUrWDNW1xNI6+oUsBheWrazDsLA+teCy8A7jHYqeJDWia8+5ebuTO6gnUiWWF0okiwdKOPNNSjBm 0LySG+Y6f2nOXke3IgSCvRPxvjsJqto2spJnJntUewneHPKgFBWK1jXlb0p4Zg5t4f7ZC9lBeFzq OgnKLr9S2cmYM89TJveJSbSXjoF6I2m0N5yH0Zu4Vj5Jb9/kKIgMqw1PVkl0EGG5vH6IiKZwR48q TqXeNTKVbaQpTLQ8ox/GhKQD2S6XmZV5yqWfmR6XJ+GXOj3SpWiEc2Ad7WimFUXFEEWWQJw2u0uR YikdypKHDTRXt+JN6RAkH6Bfz6i/pWadeh6E3mW8TBbfGDCfifW/U9dM0vLlvrPAPhRaLTR0n2wT yjdMIn3HqKYNw0ZmfNGWzcFgZJVJxHsrE4gmkTDPkcuQvtF1ec3LOuGdW3wxyjs/ycuFI6LLvVGE PYi6bwPiI18OrvlPnKzIL51RjC0jZNr/h+FHDAWT5uT6yupweSfpFZ1248JwezGIAvrlNKRbNunU 7Pq2zYHz2v4SyimFhnkC9+KxTRAkHc1xD21/plXmBiT/Nre1Edtz30wy0+TJiJh+yR/f6oXVAoh7 sp6ZP5v5mhqjnma8JyYBiZbQHWfeIxp3wdCSxo0V/nbUv1OiRPPdcU7vLMLqf+PAR5L+BSg2FALp bAxsiEgOW0Zc60UqFpftDNnIaUuplstIs84ykl0ukgQLOxRllX+n7akwJKcCmX3bcKkyOwrDrlAG YF5TQ4tIfejM91GFcDS2ppwnhVhZBplv7e4AqHWwKM9ShEpv61N7/O8+D5buaIbDkdMYhaaHN8aZ SnQphfCemKSzcJXrmblmDz/k7Wcy7cO4p0T5RZx9ddynJ86p+PEtsLKrctsiOAZqnlItuQO1WaE9 axT+XKdSNKBzTAplZag1ym1GaPvYe8rXMghiPvWVG0S9yeqTgl62YY8ARqNeq9C23p26TC4kaIzl A8NCJsuTaes870QMELJOgZD9T8hMVuegJXAGLCo2Jc/7gitRQVinLjikRexJcI1tMA1U9ypuywAR zDPskUAChFxDjTVxowmNsdyjrVZMmlvAlOo2eQNxHLSQZvgsWIgdI1Fv5IKK0KkqpxpLxGSfaIBR uEOkNaQIwRbZ1mJa4BGCR62UOqjoPOdMxz4fs5FjeSKqGTyKpKOQ6Em0t6Bel/RHhb9ntSnAKHMy wi7n2IeYRzpD5kXzHTLs6+3VfwcAK0+QzwplbmRzdHJlYW0NZW5kb2JqDTQxIDAgb2JqDTw8IA0v VHlwZSAvRm9udERlc2NyaXB0b3IgDS9Bc2NlbnQgMCANL0NhcEhlaWdodCAwIA0vRGVzY2VudCAw IA0vRmxhZ3MgNCANL0ZvbnRCQm94IFsgLTE4MCAtMjkzIDEwOTAgMTAxMCBdIA0vRm9udE5hbWUg L0hBRkxMTitTeW1ib2wgDS9JdGFsaWNBbmdsZSAwIA0vU3RlbVYgODUgDS9DaGFyU2V0ICgvYnVs bGV0L3NwYWNlKQ0vRm9udEZpbGUzIDQzIDAgUiANPj4gDWVuZG9iag00MiAwIG9iag08PCANL1R5 cGUgL0VuY29kaW5nIA0vRGlmZmVyZW5jZXMgWyAxIC9idWxsZXQgL3NwYWNlIF0gDT4+IA1lbmRv YmoNNDMgMCBvYmoNPDwgL0ZpbHRlciAvRmxhdGVEZWNvZGUgL0xlbmd0aCAyNTUgL1N1YnR5cGUg L1R5cGUxQyA+PiANc3RyZWFtDQpIiWJkYGFiYGRk5PNwdPPx8dMOrsxNys8BiVj8kGb4IcP4Q5bp hyzzD3GWH7I8Yr89fu/8de1XG6vcAsb/3d0Qkof9e7jA92j+7wmCM75PFmJgZmTkSM40MDDUMzCw cM4vqCzKTM8oUdBI1lQwtLQw1QGR5mDSEkRaGoBJcwXHlPykVIXgyuKS1NxiBc+85PyigvyixJLU FD0Fx5wcBbAxxQpFqcWpRWVAQahTGRiYFLYzMDAylIBsZmHX/d7HB0Q/Er6zfv/DuPf7H+Yfet93 ir6zuqOhbmWl0SOnftvqfY/cuzu338vzVcz7aTrrd+wMtudcD7gBAgwAHgtdwQplbmRzdHJlYW0N ZW5kb2JqDTQ0IDAgb2JqDTw8IA0vVHlwZSAvRm9udCANL1N1YnR5cGUgL1R5cGUxIA0vRmlyc3RD aGFyIDMyIA0vTGFzdENoYXIgMTgxIA0vV2lkdGhzIFsgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAg NjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCANNjAwIDYwMCA2MDAg NjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIA02MDAg NjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2 MDAgDTYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2 MDAgNjAwIDYwMCANNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2 MDAgNjAwIDYwMCA2MDAgNjAwIA02MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2 MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgDTYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2 MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCANNjAwIDYwMCA2MDAgNjAwIDYwMCA2 MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIA02MDAgNjAwIDYwMCA2 MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgDTYwMCA2 MDAgNjAwIDYwMCA2MDAgXSANL0VuY29kaW5nIC9XaW5BbnNpRW5jb2RpbmcgDS9CYXNlRm9udCAv SEFGTE1KK0NvdXJpZXIgDS9Gb250RGVzY3JpcHRvciA0NSAwIFIgDT4+IA1lbmRvYmoNNDUgMCBv YmoNPDwgDS9UeXBlIC9Gb250RGVzY3JpcHRvciANL0FzY2VudCA2MjkgDS9DYXBIZWlnaHQgNTYy IA0vRGVzY2VudCAtMTU3IA0vRmxhZ3MgMzUgDS9Gb250QkJveCBbIC0yOCAtMjUwIDYyOCA4MDUg XSANL0ZvbnROYW1lIC9IQUZMTUorQ291cmllciANL0l0YWxpY0FuZ2xlIDAgDS9TdGVtViA1MSAN L1hIZWlnaHQgNDI2IA0vQ2hhclNldCAoL28vc3BhY2UpDS9Gb250RmlsZTMgNTEgMCBSIA0+PiAN ZW5kb2JqDTQ2IDAgb2JqDTw8IA0vVHlwZSAvRm9udCANL1N1YnR5cGUgL1R5cGUxIA0vRmlyc3RD aGFyIDEgDS9MYXN0Q2hhciAyIA0vV2lkdGhzIFsgNDYwIDI1MCBdIA0vRW5jb2RpbmcgNDIgMCBS IA0vQmFzZUZvbnQgL0hBRkxMTitTeW1ib2wgDS9Gb250RGVzY3JpcHRvciA0MSAwIFIgDS9Ub1Vu aWNvZGUgNDcgMCBSIA0+PiANZW5kb2JqDTQ3IDAgb2JqDTw8IC9GaWx0ZXIgL0ZsYXRlRGVjb2Rl IC9MZW5ndGggMjE4ID4+IA1zdHJlYW0NCkiJVFA9b8QgDN35FR6v6gBhjliuS4Z+qGm7E3AipMMg Qob8+wJHT+rgJ9nPz342v04vE7kM/CMFM2OG1ZFNuIcjGYQFN0cwSLDO5J41NF5H4EU8n3tGP9Ea YBwZ/yzkntMJl/n0S7g9iyfg78licrTB5Wv4/imF+Yjxhh4pgwClwOLK+PVVxzftsdBd2upDXxgs 7lEbTJo2hFEMqoBUgGT/c0zeFct6T3trBSmkVKzJOggpFCsj/prrtHraw4w5Uio+2/3NYjXlCB8v iiFWDzXYrwADAIr5bH8KZW5kc3RyZWFtDWVuZG9iag00OCAwIG9iag08PCANL1R5cGUgL0V4dEdT dGF0ZSANL1NBIGZhbHNlIA0vU00gMC4wMiANPj4gDWVuZG9iag00OSAwIG9iag08PCAvRmlsdGVy IC9GbGF0ZURlY29kZSAvTGVuZ3RoIDE0NjY2IC9TdWJ0eXBlIC9UeXBlMUMgPj4gDXN0cmVhbQ0K SIl8VGtYE1caTggzQYSoGQZwIjODd1FJ8MLdzCCCxVIEweKtKJqoQEJCEokWQRZQwIAgigIqBrmj oIUiurhQ8PGGslpZHpXtCtStumpvKj1DD9YNtj/6Z/fP95z3fN/7Pt/tHD7P2orH5/PtouLUSv3C NRp1bOI4XsxJeNw0PudixZECbqo1R9k5Qn+Y+OveXx0R0sx/bzL9bu2EoHxK+7TATDEP4fNtyqob WmUyD3eZzCtQo92ji9ux00DP3TaP9vDxXrpg3Hp9sD7j1kdGByg0W5V05B69QanW0yGJ2zQ6rUYX a1Aq3Gk6QKWi14wr6Ok1Sr1Sl2y5/ZAnHaenY2mDLlahVMfqEmjNdjo0LlFj2KNV0gEr6dhEhVSj o+MsPP2urfo4RVysLk6p/4P7ocYPxz/XzON9Z2kET8BDeGt4p/g2/GKrcIFYECUwCbqtt1nnWF+z fmg9imDIZ8gR5Am6Cs1BXwhDhLuFYzabbU7bwAn0hOUTFBMe2Rbb/jaxYOL3duF2t+197C+KXEWf ik5Ocpq0ddK9yR6TMya/nZIw5ak4XFwufo9FYkMOSQ6PcAkeiG/Gs/EmvMtR6FjkOOIU4nTHWeK8 c6rf1BbCntASYxI/yeC0sGlHXSa7ZLgMk9vJZoqgdtEonevKd5W7FrhWuo5MZ6cXzJgy4+qMwZmK mc9nnZ89fXbY7JtzouaUzhmcq577cu7YPI2bk5uvW6lbh9tv8/XzXywwLuhbeNld5r7ePcO9xv2t VChdIo2SFkpvymxlq2VpMrOsxUPnARZFL7q/OH/xjSVpSy4uFS1N95zkedTzrudzr0iv1947vcd8 5vmc9p3hu8u3wPeG30q/n/z9/OGyycuyll2WO8u75Lfl/fJB+X/kb+TvGJSZzBDMTMad8WTkTDAT xqxjtjIqJplJZw4yR5lypo5pZq4w15l7zAAzzDxnfmR+Yd6x1uxEVsxOZWl2DitlvViGXcmGsWvZ Tew2Np5NYvew6Ww2e4gtZk+ylexZWkSL9Blv/8nlmIxi4DjiCnhYHRYOIsAK3I53icOQ3iPpHRsk W9NjFDENcO3hIOoo5CFYThH8xBJQ2VB2vk5fpUrUG1TKs2lmStTBBYJci9bDocEhTIsVgk4u0BJY 3F0B7GuJGkPpbqMhVaupgPbFUSRmhnMd/5dTBFTdgOjmF3L7BFwCqMTnoKcBgbztdkPrQQwSgaph DAKnog0fgGoc2EYBKzQZEgi0ifoFjYcq5Bp6DqgQQFj846BhHPBRSIII3DgeR6Bmi6bIVMuN1Ijb yrL63zQCdGBTGfaCW8bl4EAg3NwcdGTTYZueuFAhNgCxzHUBK4h530Y/XUfCJiH2amFU50+7qL3Q Ef285kbcD5Iljd8K35Y+uQSEBOB93ATxfhIctDA79vcnm6GVDQxxx1e3bDn7FVFx+O+vTpBN8BWO vepRdCSsIGb57o3fT4o4rakeHG88cRbsrKqsF998AHRVdx6ApGqsLX10PifEodUM6OAaXL/yObAf AG5A8Hp50Q6qJAFvqd+xwTMIUks+Nl093doFIl9RseA7XIGqE7YqvSTRe0pLUijsfXppSmrJZxJo 6wZd5szu23kJ4A+B9A1l0TfnFGeXkvvLjmc3S7pqy0rOUPm58Od3Vkg7auGtB//GFYby7sePwILe 8rSUlB7q8O5D6Z8T0NoP2vpZUvdJ64y+D340g8Sz4tZndweAx1dYB2jkuvBbF6q+vHg+br23xyZt Kmn80tjZTnDLoRMOVcnohZyaA0oi7BOfRCW57lZM344+m9v1T9u+Jx6Eti2fHe0ZuLEkviKMVO5C QpSy4BkEdHqTdBNM7Lna1EKq626EfSMZaQP8gjwKS9t7DFHrjYZoScCqR6UZVM+QyXThTvVl59q/ 1RecL7TBOsb64S78yT8uX6ojW/06F10LsokI3pBlkKyIuP2QEum5IJANeYAnHgCUohkLx8wjXJBl g+uL/9V7n3gcUWLQxe/dsu38X6qLCvPyDpF5BYfy8iVFRQcydqfEhMRaFEa9jfz2YQFoH/XGoVQq hW6QJSB5LvBKIPlFZG/QNdXxE85QDvgmoPmZAEUvH/VfJ3+ngY3Dgi9gEA6kz55ZBssSgIzv29BH Kq+GfB3RsC/FGcgh3wQ1swhYNH9ZQLjlkZzipGNE8tBg39CQUXwPvIeR5djnWNY9DrMknX4kufpM 4eEL58iqWpOpozEvy/no6h1rVYTuVOrJqtIz5WS9puQHokhYlIMk3Tojb5OUnzxeeZ1V+XZQmYXI 6zs3Ym8Ttfoj+7Ynrdy+iszKRqqFnTXtNURJZnVSltqkIDdXpfkSacKOBXldMRLtfm1WxHDF3S3U sSzEK8L3XCghAtvMyUDbywf5vQKQD5pxqAkBGqjtBVqg6YUaoA1BRfR+wPNOFgNZM7blMXTFMfP/ bze25c8NB5/28JvBQUEzKMZDwcEeoYhOBwL+10AgAFPSLW0wN5280JBUrVbrdAnKxhTLN+VflDwa bORngCsC0GKZ00co3PMuGLmLilKrR8XV/MqXoOSlABwaJXHgkA8LVvrnwizoAB1yQcY3d/NBAXCg qq1haCw0Qlto3woNIBSEtgIDsAe2scAIQymRqWx0nmWkcZZVsHUEdWUoazzWTnGvhJn58CMZkiqs uGoyHZc0mpKSqbH1woDtuRG5pMj0gDvTzwdPhwWcBrjgaYVIqGJ3znYJzESBP1iBtP118OkIAaw9 7soWL9wI56tJ8wGkq6L+wVMJsK2SrmO3eCxxp/7LdpUARXFmYSdDdxONmNDbKN2mJ15kN8YjeALi ggIeaAVQwHMRCYoIQjgHcBi5BjkFlGMQBsPhcAw3iIiKWaIkAqIocphIYlwlq2U5ifp+6qdq90ey 627F6urq7r/+9733/ve+915jB+xMKRHPGClq0aNOY+gb9r7N3oRFcJ+7mVaqqpUbdvnm2gbxNvvX LBadvDv2ClEh8QHuD1Ql8Bm89zPMhVkrazwLZeyPPefOnvuabwr8BXMbzf3wTC8xP5HS5jcPPRL6 a912LLHZvfQIcRaiHLuQc7hxbiPED7Fy5AdR3ALk7EHjG+POlCNUM+x5bDXIsHKw0jN4YxeH42mI hVEqjRx6HfpmWALolhQ2oXsc7KBzTqWcSpfVP4zNoo4eiz32pYC9aSzBMVT88fSETAGmJIL9Hryc x0a22zaLroHfOQpeKUdiDl4IHgZzeOclmD48Vr6vXeZ0e1GBldrQSKFFBq0Qf1pSPQon/iFFLmM2 HFbF4bV4M/bg8QH9pzAVHGph2R3grQfmbAtT+m4XNWD0DARw0Bri/biBe1nx8XxM7XXfYrOxH9Z0 ZpdkZ8tKSmtPVgtGeWFotF9ShGylyHXsE26cpqM89s0viKPadYXl3QL403jX+CjVTYPP2FyKWDNm pDXuGLDvh4Cb2wfYUfCBbo59CIxFs78tb7/Hc4vl3u5BkR191NZQVSbipdiSs+6xgPdFsslSBwbt N8KuYv6JjB38uvxe82N+YGsPplaYuZpZNh4asSWC5hv2+y3n2cF7aAHXVnXl7mCN6/Zl2w54B4kH i82/GeKNNGEQdw4ZaCUVjyH+qfRaKAdZp8EMXMCHB6uFQOEZ2MQKT8GmFq3YEPhLVwrrWsS0pISg 7STpVV6mcA3GuIjjyugYMTLMM8JXmBMK7w78UDw6AqYp2N2JsIzQEFJBavw9SGey+2A2PH8bG8kY gA3eytLXZQF+nURQNrCBryaKQ7kud7j7Fj/ilBt2bPfx7Qcqoqv+rzj4vCkO7NJ65PvWCgBeeWES LcqQIl0nN24NrojcVC8znoEjqa0MmniQTfBeD/A9kgqUKkWVyIQbT92EUmnMG0y+vIHRdnIbiBRE Ut8RDPIgX9bYlTJ6EPcCtVYY917uhimbC4Yes8/Zp3AcVnPqn8oa/95lWFFz/tZlvj22OFAnlgdv KncRHBbtMzuUfaRRm1NSIKv1zj3L6y5rmwd1Gz/3kjtEeIkBjlSCItjBiWczsrHNW8cw9K2iAabq Dp+Dihb4sNIYDEdgeh+a3siOoJtoHse24znRW+08BZ+Akk6Y/vB2m4wdqcgL8ZSBIR7mvnRxDzUX 8DoS9w9hHgTBnwg7FoHjC7wQ0yt24amWf8u8mJ8u64YsyoGO8aZKopVaMlEIW/FaexkBp3qV2lTx amZra06hYRrNjkQnlzj3CDDtBszWgzWeD8Z4C96FrfAC7Id5oLE7qId6teXXie2SFA3sbEIrwiX5 YxukY24aziNdkXP4Dk5D3bPCafzFuFLu4bcuJMg0Qh6ZFJVsKIddGiZsT0pzTro6I0/WCu9SkE83 LaQyFXm+UfwB3+QDohxOMuPRpEMAA1ripJZE93qKRl4HzY2QWyfXGAOlB5XeEhi2pmBsJvdDolpp y487MXbKyFVJRP4Bw1ZDUBGI9S+s2pYXytLIxvM5P38FUh6W4PXq5SLW0bALP+SeVKliqmVsaHvU RV8LHvN4euwm54gTdSJSG+SnqYvEbHXqGYE91/ebHE+buJICZJ8mTxikaEG/NkqIfdKxKcidi4VQ Koz2jfNNUYVu1pGI2JC/y+k4BKeB7UJYAVt+gg/SUmURhZS/33o7PEPAxnjaA1JM5rd0NdTLmpqv Fl0SYMZtq7mlk+cqr0M/Tvj6mx7RIGH9TptAHQ3XhmEHmEIIXgYSHC/DxTRbIGcGE3JiXh+AvTLq r4ki6wcuqIsrStFcAOOOwH1t4s2tJZareNyCk1Mcdyuzqsk0kkVU1ENzE5yqJ1qe6aGgWFfChqNf wJoLoM08dvrjDwT8l5TUJhmkMrA46X5yviLXyrQYjobQdsdigomPiyGIrs5NOSOCQIO0LMo8X1ZK H4d51LiWZmvlzHVVScKaCbvWhsQ6ErvC5aiOMYLdJGu+faP4ZHFzCfsMBZM2RLAZm5iIcAsBLyDY FVknSkWY/Ufs+//FtmcslEdtEknQdRrGLj089y4PAQwsSLqbXBKTs8qUnKWiEa4XQk2jcRXQ6KOn X5SxaGwnvOLwyQi6V1WUvJrHK5mDDiEb8JJ5QMEmyISPr/9TZF/AR+1/Xn9WVkzHwUEqlA5I8FXF Hd6rMxOwDzYhhFiDZ1Y4XXGWre0Dqf8zgUXwDpheVctgL9NXltZyQpwkyMUWqNNIXumhQy/VmECl hrbOiNH08LAfOrA7Y5MYumrC/koNM7mOnJi+3LyBTFGDK+VMf4KaxBa74Q5w++M68X9S3ig4RTNm oJEAo5cWmsAlDW2bFpw9NAF2rzTrTjoRuiRn7v8PU1aSEaZKUY/+RYTs9FKoRJe4fnXOUAbZ2ihn vlflKuz4cS/G/agiWPQuHdkgHIn0lysyo05HyJQ5pdHNwlmYkw5uk+n6Wvf7ein6jBDyYpImKZA/ dCQQh2EPETyZ/+DWyZle1Vfx1r/HzXrC7xri9wnl6Vs8fM6UnXk5l6o+9GS+Hx8amew2weWrGsYl yad+822sgPRZpOc59d06k96ZYarB+cxkGjeg5xOJxAbCBdLRcY2cnkwOtu5N6gXKUQ3TBuuoIBrP dHFMxJ8IqyNSG2X/ZrvKg6K4szDj2N24yZLo7Aj2pLotMeIVg6gFeO4qIpioGxUvLBW1YFFBRRiG +xCGGYaRQ1BmBob7Gu4bCQiiEiNRNNHFKNGou9FkTWWJmteTN27tryWVZKu2+o+prup67/vmvfe9 7wkhzN3ynGGxVtW/sJB0CoVjUutzMZY/jcdteowR9BTuUtG304pPEvBzGbRTxq5SE3gJZmb1KWXJ j6zgrGdAb+ugDDTkCNcovc2P9owfp0ha84PM8Nw7YjXulmVfzRrvjGSldQYRM5JvUaesy7pdTJig Ij1ZdRIZFh9pGZtMiKBwlYpuNal3tvG2Df8vMUvkTSV8aOuiCoRSGibVZl7NERMQP/mfRkk9afqV QEvhVZyc9PYscIRgiEZ3Iqwe5HFHe4zGYJiFjuDLN05E6bv/IH5fBdLRsTGQLkUVHnvXDaX8+NiW tEKvqEo/jEEMUaVnslETqfetlDMJXmJN1+jC3VPHCa/URxtvsbCe0ZaZ08sUL4YK2zr4AlNn25cs 2aoyfLsfOQ4LaNjoJa87k0GW3ywtOuN8ZHWBysgMvUqkgN5mmF/9exrWj3CR/H395prdTdGGbX3J BfZglw8LnsMx9n9YTcIowopb8DSM695KuX0JUw8Bq8gv0mUYeHxqvSx/TS6KHGiE3GvSRyFKJM2/ XjbQ1ggNIlHyJ8SLRK0uZvl+/YnCiErcD9lO5/NgahmwLCxAz2I3Dqtp2aiKuZliTP5lJpVLxSLV mJllmUnm6yzsZC7qIRmvULCElj2z+QsP5dW5Of1t4KjBaYT3XK17OlFlf1I0a5vk84cQ92+psIXc O0o6UasOPxrmV79JsdB1C9Kzh/Y+2caDyxJT8GbW78DmZajYAVO7VVw4XYN/o0poU15BMVfTEzyi AOfhf33NQwA+KoK57KfnLb0vhhZ6FnDl9OvBEb5vlxQVQ/AYBBf/yUPYYZa7n0owD7PC6QsMTKiK wgnFfBmdCisp2xU6FVdSZWQTlVSaYYLigk1D/0UT7ip2dxcjNlunYDVLno/Bq06pVTTWGKuib6aV RU9nsZRZmnQoPoLbHbr58AriVXTAD/FwS1Szu6KakU0xojYkEpX7jNlE/Cgxomd18Nd7HBiYFwXG O6fFVsgTh0Visq6QWjeI4QNUdLO2QbOfVUYHaFM5dLFJcR58Q4Wfj2ozsrVm/UVR88wqpltbmNDm Cum2c05GGsKEyzUjBsPHp8hmeDAeM+vnRdKfPcSYZMLrNQ1pB1nlyZCTSg4n4xN0gm+p2JaEkgK2 8ZzeQkIWqZj+dGNqnUedp9N0bMCZwpuUOj+1wMBWFGV36ckXWhVzSW0IrfVodnmOTefxPXuSeIGw rAMlX2Fgg/M0Iz0Ifvfg0A3YaGgxGXpO2/+qoXnW9VLrhyKYZAImvTH9CKuKjgwP5ZBCLmCQ8vku qq6IrSnL6MsgmQZUzGV1sXYM5xI7sNgJF6Lf8rmJ8VvTpqkgzswc1AeeqmXNlpbiCg7egNnf4XTK FN7gF8UeOabbqSG16zUz27MiDQcHcCtUOhF1WH/zUcWp/sxpv4n6MNHCLSKgoyra0qw9EpeSkJLI k5ZV4mwIo5LzT5rPsFXlGedE6nUqpivNqBEBOeJWJ1zNrNKEzxF1fNDMLMyIL/iCJWsMZoPyxsu6 zEaShzRis3C/WZIrfC0VPgcv+eoI1Xp0VGAeLXgJLymjrZSJxFVUBX09/+w1cFbAcdrma3tJxQpX mDLwohxOoGu5Nbdc8nhECn3WyfJyDHo1CEHlS5hdutazvHUxY9DVdHEOy3OUVu9ISTL0SJPJYIHq lTc1TGOU1fu3GLBiRFqPjvIwCLIOYlDYQ6ZHdyCBf7WYidOF7CEDOhF6BYmkTFgqfQK9cuK428EZ 28U4voKE2kR+bBLKASf3SnSCRipocLK816bZyTicENaCHdpBmi5yCjAtB4GXNcl8IJIgedMuJMnT 14v1uBxfWl5n7GgNyjueok5P13DpaZp0rSIlJSvXbOq61s47PEq6BGolLC+b0vTY+z7MHiUupRXe kodoEo7EcurkI/ERisBQSzexvPVnLsK8Xo4Y3j3y5MT4JKUiVFddzcN25hPdDziHkz1D+91eB2LO HrVUmEuK+Vy10chamgvraroT13AbGdkLdP9gcbAL69MXeGGgv7WuiVuT1Z5eqDBZMnoIlKRa4Y2r 4GHsjJxy4wFEPpaNkrvj7/JLmUOFtYpvGmcu8I0hPcuEeeU38O4x8sAXx3phwyC4/fOnzcDgH1dt +yg8ldPCAK3WUzKbf/SuOP94+xgmIztPl63o1ClDRLZfCFS1pPyOVJgBrvIdwYH71ijcvUfIYeDy xNLUnxUVcprPjsiOKDheoZ9WozeZS9nCeEtIMWcK22MMUqAd2ovrwO2n9fdGP+sA+gKB3aczCX+o Ggde+RAiH8ga4OmYPOjkwRMBCt81F2EOvDPcc7G75/C6HF4WCvOwUu6j1hW1scIQI2I9L2Ld+Rrr 6V+xoitTfSjEsE+BE+cjg464D5wjW243NVWS82MjnamhZKH95nOmjwvsCa0bEFoLTKOk/IZUmE8O zMDwfevcFL5L22BtAg9DNDgmevW9p1iGb2/EDThjxBOkMPMyvGPJ4/EezJc/NrVUDiju5vn45/DE +RkFl1oIqJL8+EAKnwrb5PgW2NNNWX0DXHfWn9sVRaX51fV7K7egjw7XbuE9D3+F1+mV0cm+Gi4W 8o3M+/r0iissXAcHxgFDL8GskQAlzCuHQy1ZVVOqbobeX/4J7LhTWSW7PV3WMf37hfKawmJLE0de u5NKdN9q7G9re7R72G3r9uIkjnyBdFCrhZfd3ndB8JJfbyltfGhC9mjEf9mu9qCmsjO+lCaHVhe6 XKNwb3uvzup2rLtTpa1dW9Cuy7CyCqKr8kbKQ8CAgkISkhCSmIQE8oJASG4IIQGBCCgi4oP1AY4P 1tFFivjCzeponXW7u+p2eq5z7ExPsN32j87cv+583/f7zvf+6T74KK7i0V2auL8YTp0SDK0FsmqT TYQFF7P5VbZiat2KTDRvy0D2pQqGmO6IiW1QSMm9B2u7FTQxszitKCsPY8zsfP4Y/uEC5PXU3Fxs pYnZL5GgkVdmzDT7SM+xYY+Jbjyia6UuvBiCb5xRt6t8TDgODzX2Ot/TAZgcIGY5GStIb1ZZ8X2S CY7Vw3koYnOGML34dTma/12OOXMpNv+Q4ldCsF6l2a7BQStlQYZVYr1NQi0YHR5ie6lxb8EGBmWA tRJdhg5LFIPwWAwcYR8XwyXPI+88Xx0g/o45nIrlJ1h0bfj6h6DOnCpJk6RKo+XA5HCYnJSrvT6F QXIQJ9Um6WkiaoL7Jx4OEqfwiN/r7e2p8pUVy4X4MIpFewa4mdaxOdNP5kzDkBzBmoat6XSR6nIu JRHJK3edkpyGguFn8CcMlw105lRxanWqLFoGTOwPWESUFJ79vxDY9/dZ+KETB+1+gLjdtBAqWL7Y yNttqrINkzARH7s02sRrlTarNaRCoT9AS+RwD8svNxU0pV1F78EdUb3dPBgJqZ6G8xSLcmvAcdsB pfqAUl7D5JekbCsqNZiiuN+COtxR3A7pjpqM1x3VbHRQQ42yHOaVCGw/YNigpOcC+Y+gJ98EiMGO hVDJ8reYpbaLJPfVnPqzoPqOOfXW/6pXgG3VihTMjLg1WH+RQ3Mu8kEAbgp+C35OfPrgS8GGMkN+ Pc7VPhYUG3ebPiXhYWA9NTZ5rq0gkUZl4ONKfU6wRSpZkGcsNd8ioRUMeAdw5/3FmJLGoCKwUWZI 12KJvSyoMPF2Nhn9XkzrwM2a79+OTd68X0QfV5Ye/5janifMSWFmgAY7O5stzZJnKcKkwGRreZ2H TXM1usihGo+8F4DxAeLkvceCFLkiKwhezIJUc42rn4QDYPDoIY+fuuQuSmZQIVhXodsVlCjAxWip ZU+TsBrAiPju7JTC4uwM+u4c3O0gXM4cnMX+A5yqh4vpCel9DJ2PQ6GByxUgcg0KQRGIerwUCuC7 NyDzLVz23kO0iGl7lSxA8yvhppvfj5/77MlZLPYz9PaGwjQmHJW54ZY+LoxVX46cCcCqB8TsDN6d uXWiRB0thTo3+FBmx5feKiDs71EeoyAzBRfj2R297n7M2uyMvSLGYOJNAy1282+ZkkxppjyYwuaW hmbqsFmazxCzAb3gaOOFniMUDLei1ZVo/SrJ7m1ZI74gdhvceoV7q6dOHNn5AMoCmFS84uIE3oJK RxqF3lqOfoRotGIm/tGVG8f9bYwVJfPTayr/pMeOKZ0gp6XaMkriSYAryKLR89ajLwT1wgZZqiRM Uy01yKmYgqdPGGzzzbHp2afG+L10cMzC775JbFV/FnkrQFy5FRB8ItNvU+EEaFiQZiqxTJKEA1aB vhNnOmniSmdL8WGq09ne1S/uKCksEcdnMYZHc7uuN0OcXp0hw281Ndv/04nhfSqvVcQl+dTiyLMT yQ5YciPTQRyEn8PrAqKlDv6Cp+QT/jq9TqOWlnp2Ur/KTfzkg/FdE8UM0X1xN6+v2rNfSG7NkpUs lzw8X0vL+EQhWukARHdzo8XcShl7RiQnqauzxx9eLu7J8DOEH71xlbfLq+31kAc7hsZPnBQt8+JO U53j5veF3MB7xIb3yDt4jdgarBp61w55VWFBWFVVlbaW1Jv0pnr6PBrj/3K4/Oyp0/0jnbTCzlMo q6uEVFrDpUMMHHoGwlUXa53cQmfkVAAm4JLGFHX/GcFmg8F3hIRfoxgpuGGwiPJJ4iSqBbs1KvUB uqq8rKaMSlRPOBl4F71TA/yGPsNmElnBkjv7h92jlqEhemSE9z4wGXiE5HTbUeeYMyy8ScRtZ0Pa uZxQriK4+xg5v6veq64ki+LRypIV9DLYzNPbtGwr2eU1d5poFqXJgafeo2XLjsR/jeSdSWG5LlNd M9XU7Ou2M3ABvNl5qck1EGQIIU0ieF4E17IhHS9/F8p9ju3LQafOU7efrNWWK/fRq9C+P8LdmCBo 7W6yt8vcb8X2d8rBsM6uGUS8lSgzKhsuSIHEYbLHZ/EF0TfIQZfBpvBkQgo9jSpxWlVNVKPV3oMf /WOo+StS8oqcJo2NsllahlwMpOG37KC1paMpmgV4TEC/CK+ykDYuLxSOTwssutZaOSlS15UGB1k2 C6TGcmPhRbQApkV9AefbHH7/iDGaRTFy0FbvqxeRSq06+Te0pDfvipvs6DK5sUP5ctBvbG0YTv4K LY1CfLRGmF1jKNdHy+EybE/U4DYwdmdHYzN9F0bg03ZP4PfPuVE20sn9mRjk9gZDTsn5fUaXSkKq FUJVOR2H9iEAG3n6Jo3LQXYfNvqMGCavBjgMB3Wt+yAf1Uc5S0d/LSdl+YhOpYlyRam7nMo2FGrx UVzhE56ZOXENkmdpTJreZfFOd5iiwx82+DnSHzLuCuVWQ0pQbeHFybSlSyhE86GXW85j0XdAj37K c/PHmiwD0xSk+aj91XJME94E4TACJdpf3rOHwKSboTApD0+0CfEL2g7iXeKjkySMBVOKobg22gTu uB1DU8Efk56jUy4ssTRJjOYxKAHP+tKEanpS4irdSIajVa/JxPVroddrBNdeJiTy/wekAoOMcoMC OD/Js5RWgimZpzCBRLEg3lFwR0obQFy1oiA++CNBXBgvwxIvJjxwHgMTwFXXocl2OsEtO3SVDIeb 4Eb4L9qrNaipMw3DxCTYkXTNaVo9ZzxHdztWy4xdu4PYdndFlC5eEFBcBYyAyv0eEkjKnQQOuRBi uAQCxCTcEu4Xlbu4eIcFi63i2Cri1LG7QNdu676n87kze1h3d7Yz+2N1pnPmnB/nvN/zvt+Z93ve 51n/u0lhH3MCi8CsTDTMstM6ViqJPkmkRp2pjabqok6Z4wi/mPBIGdUVwu2sbejuJwa7P1G0UYr2 tuxu4kZ7/zknKxJRMlPyPD2Dufu9cPHZBnDBYjEDvA2dLN7x5xh3j7Lq6AhxtmqgdyARDhfNUIXg wsU2qcCfDchIyI1KbJA6WhsaHV2J5nRKUPh5RAbj4yzOFF68izmYd5hZUSwPqw5HP+NisXp5VmkW 8Ytl7b0toQKt/Nth6ih6l9vBGwGSpb/i+hraRjy6ev27ISq3nOsrPpHkT0izDUY59RT6uTG15iwH Ya+3NHUkdEXUUOh99I3oWE/G5Wkc1j7oHrNV08XVpEDZkvqgvgtCB8DRLDQ1PXwIHl9hY7DIrBSh 1TzVZbrtAt5Z/vSRqV97JF4b19fYYOkYFA95/XyrD/JK0OeUZZDrj4MLz7S1wj8Op9UFrN3SZ+eU ZhPBUSmhEZ2KtsEmZ1szheUl9g8lXSCGe+sdTqqn2zxagRtKtCVkhmzve0TCIWOLP9UEb2m16qua 5jUg4GFjyIKui2QKs7XJYmppbCtUFmQdC2NH1sEXPYN+zdAcmGONn5j3PIQ1oSM8gdYCXn2P+6Df 4goHH3IALKKDOmnNHfxz2NmHds7yjTVc+LAPbeQ9gf0d012twxVrLeiInN+pdxak41lFucpsEq1A qeg1SOMqzcV1JtxaXzmkIS2IlvMvaKxxg9v/jHauQW+fhI94xhzuDuRzEnz8+TuU0t1qUg4lrPYP amB6WkHlcDXeB/zBX+Y4zG7GQ4SEPFhjqgGXPxJVVep8qjA3LwvPM8kaG+x1Tkdi9xG0MRGlhKjI 9byCRC5weOrs/EDVgeKAtdnIm7tdpfhlIJGvPG2kKs1VFtyeUyPLjVfGRDkSRheGvoVd7aT5XvlX dbDKDVbxBGiTFQxWKLBCmVU4c1H+rQer9ZeOXcobwxjvGbZdQx1Bn/6exL7Ph41oRW1WJB4Smxwa LG+oIqs7KjvwuuyG+LQURczB6xH3FgcmJi6lte+5RJayY/ev3vPK/olp/OqJP4T1kWgdcLkSa2Hr GdxuGbpGYt+5DNqyFZQqLjsBz6lI7mFPkvPKgd59Ph9Hefmdix0Xk2p26jDe2yuPBO3EQfBUNA4Y cgkMj0uLPhY60BNFZVglTWdxtk+cpAD4kzA+6dp5E4ZucqCMkYnmbvh+9IG/r5fXvpn7X0zOzFGo 6flK0WjIwhJX2jqoGCVGB+vtDmpp8/CoxwLX3l7bP4qPZvVLW8mFpbDhzR5ce7K4NoQICc+SxlMe CyFhS5u50mSFOAQPqQ1vjCcFyJfZBWptpnD44TJXPGV2sSe3ctwG7i14s7RGninNSU2xIffKYFLw iPEFF+QCNBt+vvcUUF8vP7CzmB+8x/blKpekgg/27Ma3X8m1N7abz/fFVKapijXsCdHQJRo1oVIZ Kiy1A1PnKMwH0i0vES9oZzDhOZAgCfM+koAEs2IXz0Emi6C+va+ykDw0Ob6/nB2HZcbqlD5FAyVz nuqXOd1sjmewrgY3qsuUtFabl0fu2+8XGJ/ixlKYZ+qrLhaks8W4ToCEM/HqFbwAGWZBwA4SFqV0 52RBBXlpX/CEkigqplW5LSfr0ylbUm+4LclNlrwBrcvBVaV0eZlWazKRkxPTV9tb3AQQxjqAd9oq MyG5UfjNHASwLrWV2Sa6ie7yfBXK0OXpnmrm++nVzj4cHvCtsFKtqabai/X5UTiq4weoFX70i5ij ZVmVN3FsBMz8Rt1ZXRtJs4b2y6L4CDqaQFt5mmntkMnp5jB1dA7dpr0uEpbaujNjB87sRet9tqFN xdTHvH9XA/htdbPw6RwEstW0sdV8iqZ42+SaEPqFKYosSzaM4/AEAtEjvn88HbfsRhLM/CB9Ud0g zizyl9XuoiZPnJ5DYF+mZTbuJyLRajmK11C7efCnN1Eg77FaDW4zV3J33SCwxQp9mV5PCUA84qpl SjigXxHKlIzwBczeekjNdIUiGwfMaLNIx+oQeJ39BZZeMvK8dmEQL5ovTxkk6u0Vna1Sk0KsjFd7 Uhpw72Y1fqPMlp6WIZOEddMa5E6WeirbxYRCmpcYay+sHyxvOT1PibUekRFk3Sk7WlmKXteh19cI puvh2YukSiuHOcAEi/4DTP7/wDGlv4o4TJ6PKvE4gZ/2VLYsfy+MTbTnsd/bS+cpHXKPpsNwiVXW 1GCzNQ5Hl+nAnVTPl8cvb8bU2imtYHOmFHlSZ+n5gWHy+Jjhcdd/bZYSrIcw4LjOAIcDqyGMbT9r Z113a1pTUpJEkhDVkWWlBAtoC6uPbLBkc5XNwmtTV6Y4UPjDG6Irf++ELTbebwwFlimcecK/Zaqe Pc2Oi1o+ejfwEFqDhNe9YS2FLvO9aZkXTcpgC38Pc1i0yyDuBxE7i3scXxhIgQqOgt21D+wcmIA5 toI7Ade8dwQEeOtI72sBd+5cu36b9U5oA9DbM4T3gDrViwVi1mdoAxvqrLw/dQt/EFQtlcRnR5zs KmgyGnQ6Pakr0+tKCaOxuFCedXxPJCV49K/1A8vrv/4nSDBm/eylQLASKJK/VFKWJGmWJF2Ezh+l vcz4/pRplxmy/0cMaWCOvzq1YBeRZ/Mr89IPb+Wz/QUc9pK8uN9IhQ/z/1ejrXKB+Tdf4j2LLW+G oRa6GT5p6msWGm9BUMOlz+Cg/e7yA5t9iP3W5R+MV2tYFNcZdl1nhlpFwzgYd/rMWC+JWoqNiZoo glGTKohS5KKCoEHluiuXlV0WFnaBBRYWFgjucr8sC+yC3OQqQUA0SgHRVJvHGC8VqwlGjJq235BD +nSg/muePP0zP+a83zlnzvueeb+XG5nyoQLxD12k0r2rc8dcaSTcgn61Cf3mu6SqlyOwbLJUa9Qa WGVnflYRfcdsNlWw2drppT/RWA9OOs7x4DypNgs4PLEwxQl5ySa1TVVyTpq/aIs3WuDip+psYMiL Ku7IWmr971atRPiDU623H34Hq6+GfebGGk9RjXXivfsC0fL1IfLm1os9sOUuSw4chVd1/z+el67E yp3/h531mwaY414Kc/p4mz0L/tBDKTdGBXm52YhDAj46KPItkNaGMZLqa5LL9I2JzheNakvQKVWM gg1uTYoUhR08dcw5bOxqW/mNsjambgTLK6q+cUVEeqhh+8826DGcHlwE5RAjhDROT6G3YQ1mis7I iqcjMiXa2FKlMYUFx3XYa+C3IBXCMh4Ijs+wM3kVhSaRPrMuXJmaJZUy6G20Zgb4rxGBAUaE8OXM hG/AVswdR4vRVr6xh4WvwHbVDMZy6cA/7XRwn5ftURicsuM3F6RQqiPphNiCvCQ2xogZpafzYund Ys/AFNaCl+YZLK20sTBNY2RNKkxpqVTX01+V3WwsmPmGrouzKxq4ScobRi4SM7u9+kwmqLEIoX7K gTokV/i70G4nm4fUrARHAu11v5s0LDGCXX3OTH3F9wKYPymE+dwXlKxI3FhrqqqrlZoiwxIi5Mzs uF3Z5IvJpeRAGY9YMOd/MGQl+Nn/zHu+tqARljYKxmaewjEOKO+OgMuD3V2DgwHdXgeOHvFmnl+j Wizi4GCJ5ESAvN1cXdHePZPDwpu+bhXAvi+Fk2uo/DRMf6Y4y0Bbi5OkoVGq8JSTufkKVhmBaYqr 1b3035o72rvDzb5JqZnaZNY8ioXgrwnL4BYLwfuXCEM29r9AJvrgkmDkkhDidlDy07EKMR0XV2y2 1pjLitgjuDQ+Ijhc5NNwqrO7reWcmZldc+tr8qc2UaE4sl2FFr7CQnGYEcCfcf4yz9r2jwmztv1j woxtW7LK5a0Qfc7aApkXgptlFXbciueQXtlgIr0Hpi5zZRT8dnqIID8dkBFDFlVMSpo6PYVF2ml5 yMdxGSGaZTxMDn4E2TFQTiRmH8iuEzV0P+r5OwO7kAPOD+6KTz6Qyii0mJzLJ7rACYvB0VzPENkK 2gXfk6HvZSEZVhPjuf4+eWwlJMbiuzQJUUjI/0RAgVtKdAZmHAf79tS1BpaMG5juQ9EU/AGuYTl8 n2O7hWOag3sgqM5OP3zw6r2/kFLYwEmoTE1WqjrZJkMjS1HSMfFllnJT1fUqlr/S85CA0qQma5Lo xCyjiQWCOJs6vG57aEi40qCoqDAWFjL6jIICkcFsqDQZFdGMmCClvw/1iN0vCmg53dTUVF1RwZDt gfm1WUbaUKGz1PK9UD5/hue4F+V2z1+SkdxT2EFF42ipp1s6Wke/H6drYyGHgPUTWC+B1jtgsJO4 Y86/rudtvElODKdVa5xESEq8540dJsYHMLIFORPO0mS3dIaMlHNNPEcCZTP372ZBI+CcM+BCrppr oSyHy3Y7ilDk6g1I6Otbcf4EE91ESXoV15+IQA7Cuy97++VH2hj+qN6lDuM7l2NnffaVuNPofbQZ 2SAF+nW3400P1gGxfLK9AzZYWN+QYpSGPfAWLIVQeMPvyUefs7w8NC0RrdDVAoXN4mbeY+dBx/cQ X1VvImWqqTuz6kB3iOMns3USlmxWZUtkulQauSJ2FdKj4/AmmgdrrZZsnZXlC7Kt9TorDa/w/8rA E80NiPfTosXaN4Nl2V0saAlwyM9Um9kG9Rlx7mGbKkg8ja9TarJQMA0qolyfO8T04TCve1YMzarp JdMiykfpvxmt9AN72Abv9cMKYB4ZvA4xtv4ccxYizgryboHDLSG8w0emdd6uTi5X3B+A4Pz90Xvu /ZvYtDDqgmW/y94gRdgfVT90dDXUtPN8Dqs/8xuDSCsstsRU27WOuz6EJV/D1qekWDU1Bxwpn7BD gV40WpIFC5+zUIxfSFfBMrSCPihOCvuErYyRVO+hyXDVxp0B7ifMqtIL6efLtWymAWtLbyxppa9p fVels/xcaKPrh+J3RMca3O6Ptjee62GiSq3+D+nWiUJ4a4glO1TTejE1bK6DRZ2MzhfT7SoLSRUp PYOPeykGaxhQgAfVka2/d5++mbs5iLV14vPAIsOgTPD0gbDEHtTF+Mf6tNJrIgAiPQet98ISiOzC wuwiuqQ804NFCcQ2hcY9g5mpA1Ms/FTUJbObfEDerrQHVTH+pxzFp5+LoJu43Y91Ec4+GB9V0vmo wPkofJQ+iTbxhM5YoCukz+XFB7AokNjmgwUSX/VjKI7wikv0SGds1XXchjqB5TEUPRbCt9xcquZo 0X43EVq5+8TB4MiSGhkDBi6JOs7rQIAZJeF5ITQSfYAEaNGm5h1Xj7E70HKsBR/lc4TSUp/aSIPD F8A+/+bk9X2tLApD41TElZR7naIfBvuHG2oSpVUMf1HUNVGvibOzPoaY2/DuU7KPTJzaCqspSexR DzcaLdKAU7+WhXwcNqH5lZ9sDwuIkDI3vFzzJTTaKUa7PViyDzmDzb6J6r/qn3Qze81t4aP0s957 Y/XsdBB0UyDIR06eCI9y2YaIdNh7FxaMWjtY8EKLKUv207u9dYf9mEjCNtkiK4aJRiivtbv1oOnR xXH/CTLuP6RXe1BTZxZvDLm31JW13L1Sb7r32trq4KC7iqtWXNnV6oqFRd6EhKeFAStEDRBEomsR BW6iPASWEJIVZHiJPOTRGoQC1kc0LFinKmqh9bUP1+rY3XOdj93ZL1xM+4edcWcnk/mdfN85X86c 33fOd07FHHhX+JSoMtz/hqWyradiF3M4J2cPpDDUmbSzddZE1qTripvPrPp4Y+jOguqKQrbgmMxS kGPZJd+ZpU3LMClug+TP397HeefSs/EoZyCpbJBaazpHmH95nVqPNhWi1f7sJEFu1hQmYXaDoaZW cMcz0oxbUtDjhibRkFXUwMDfSd1h9FqoLJ38YyvPl8pL+Jy9HCoj0zS49WA1EEK6wVa4apcIyXap kAyv0HZomtT7CZsJN6TIhA/bki4Kb2vdz9+B8DtUr7BOCKe90R1i1764xEh5oLp9gINz3pPzyADN xkBGVZbS2lrWcvp86kienTUYZIHNA7iH6Otv7WvgDESCKbq/tb7sdAtbSlK3tJm63Bz5R3xXDe4/ pVBuEV6xSBot4HoFXC0gq4ORK47paA59hug0bU86ylnuoH94W4i2o6amLnkvshFKAx+Rx2rB10JG FBt4KyP4+tLlBHjBBZkB5RDKw+L+2uf7UEqerKjuMbCWd0i0HF1ES+CiDM3SEg312tQKDhnI2Nzs 2EPYxMNCxhzJNfUwoDY4SjMu/W3Q1APmtiyz+9MnAgESKpM6WfXMg76eV77/twwKXxX7FUogN+zb 44tLemYWtJFwbgxPZHMhHXmDBB3gUA0Bd9EQjRaAlrDw5tPgPrQjzsqOBNSuXsmgHlTIf6DcV9LC wn5YgP/15/zloExoq+21QY3WffyWsO0BpuAhLnHRBJUzqfj3RlzVv4ALL0821Sf8CQXQ2SU5mn0F msK5aBbx9YSsoX5wwM4MB3du+k3UziVq9rhO1lFV39QtP3NMlZq6XaEI4TznydKh2HFZeDtst0vA YJc2zhH09kk9AWo4SSO1H6jRcjssB7UdqWGZH+EGSt4M3CnobQepWfLtE9gDEin0mum1hmzjVaaf LKg1F9bKv7tU3dnNmap6Om8wQLxlR0tYHyL/gbFirORVM2rMIq8eKN/3PjO5gVzPp6/MY7PgBLlY iKdPlPONPbCgEM1HXojhkzK1egNuB3HYYCGal/n0LPzUkRPu924Jq0cp87MEWEiHQrmKoNaiWGSW RcEmkjIvHSWptfcGsYReP0sjOYEJe19mwI/XPx1hjpkOc+f/EmYcpv14RJtph5mOkU2LR7UJoQl2 4LYWB8yPxHNYEQS8eHKb9HZ50YSGluqebZQM26XDOpyiDX4EsC5T6NYtMC2Q1iI52wEfdkhBJayh g6L7Pv/8U8c3MigoOjKIS3G5abPdvOlv8/Hx9/fxsfnfxCemVkNQs+B2HlYZ8Zvw5ThkfE09+hJ5 0HGHMv0OsbvhYDW5fk/5JQ6Wkh+dqP/DKTlwV2AekDDX9/aytdFR6gyuwCDTg5U4eFhG/UeZHaVT Tj0ZxWV8sbyHz0zlxlEu3V48VN8qB7citCIdrVuatS1U1Y1z/gc8kVawDblD0LXQWzA4SlX+gKr3 vqeq0kHVew6qKl9IlXKaqiW4Naw5LDuX37Itktm1NyGQTUnvSJVn7M3KVl7IN4Jn3+3ea+GN2yo4 qrq97lhdM9Og7l8ZG5axLoU9vlt2vNrSbJV3GTU7E5N2bdnNOWrrZWiySSDgAb69AP9H+ggLdV0w uzTXCAvNsMYMRJd7+yCsvwQuw/DLQar/M1ALBvrMwUJ9DIPyyDg9rzjI5sAKI6ko0vPdzCMrSY1/ tvjS8d81yy+VElnG7S07W4PH3vjE2NLez9hC6rewaAMBsiy6k+ho1gaHaxOjuDhCYPJpCEGe8AsU gsLRIuTAEFiEFkM4hIAnLIYQNnQOLokUehstQysQhTus5fArcIf5sBJLr+P1FazjrdhhlzQKeunU dZ66zGIHABqtowkw4iagqppGP9GA/7UnQ/22q6O/xv/maAa4EmGA7os6+fuywIKCNzrjUqri5Wju KtwJeCDq/jtAO17+ZfAmzIwBaskN7r51W6OXIqEuwrTlyNz4dOuBT7Sn0nDIPziRKsOOCGFaSbug k8JeKKZRJFJYlbjYKkCBJStSOCSIVGIJf/C6UinDRBq/v2jUyF+FuJe9JxMvc0+myJVZ4KnlSZek ffDhdeBN8OagVHDHFfvHwv6cFi7e5XmYf4wGDjwnPehobfJWP/m78de/03MP9d1f/EV+o14Vf4Qz jRKleaU5R9ijO3aVRcqR12Y0YxV662/BQJ7uKC82c1VFZYfLmapRGX7OIAKSL0O4U4pwSiqnFOaQ AiDwMsQ41yJx1ww+/DDE4nEIOEgewYc8lyKcksophblpeEi+irVEjJhG1TSGTR99Ax8tSmNOt8ac bo053RpzWow5nFHiSSX5K9g6vTbhtJ1w2k44bSectnedenedvt7Dp3wzxD/EW1MQIYJKhDARYkSI dMAjHAQMj0WDx6LBY9HgMTZYs4OHArwpYsQ0qqYxzG2chxn4JAxSrDUFESKoRAgTIdKtuZ7HRXer 46erqOoqqrqKqq6i6ixxb5boAuAccdNVPltUiTLLQMMTYCydzNGTukohvAxiKl9FaXpBUwqzedf6 18ZnCvk/g2f0fwcAax1bwgplbmRzdHJlYW0NZW5kb2JqDTUwIDAgb2JqDTw8IC9GaWx0ZXIgL0Zs YXRlRGVjb2RlIC9MZW5ndGggMTQ1NTggL1N1YnR5cGUgL1R5cGUxQyA+PiANc3RyZWFtDQpIiYyU eVBUVxaHaZvX3Wyt9OOJvMbXjSiLyC4CQr8X0YkQN0CU0eCCdLNDk25kNYjKJi3CEBZRGFGQhggo SwJIRMStLCwcCY6jJW5EY9TEZSo5Dy4p52Fmqvxjpmqqbp2659z7/eqcU/cenoHhLAMej2cSFpek 0joHqBOVM64nKzVgrXns/FksxWctDFmZ6Vzkj5Kn9kz5YVQ9771O94c1FcIx8yHrgMMSA4zHEx1t bOlyc3N3cXPzXqlOydTExcSmyh2iHOXuvj5eS2as9wfrO2N93eQrlOpdKvnGTG2qKkkrD0qOUmtS 1JrIVJXSRS5fkZgoD51R0MpDVVqVJo2LfkhTHqeVR8pTNZFKVVKkJkGujpavjUtWp2amqOQrVssj k5Wuao08juO0u3dp45RxkZo4lfbf7EyJH3YfVWxg8JTrgoGhgdAg1KCRZ8FrnpXE9+Nn8dv4jwwL DU8bPjD8DbPEPLBCbFBgIcgUDAlx4W7hcZGjqFr0dyNnoxCjL4zKjQXGgyZSk0aT96bbTW+ZLTNr FUvFYeL62dTs6Nmjc5zn7Jvzzny3+WuJVjKAL8IzLIwsqi3eE58Q8UQe0U7cJp7PXTy33dLYMtRy cJ7lvAQrd6sKq2fkWvIy+VZaKp2yDrDunE/MT5p/j7Km9lB3ZeGyZ/JYuV4+ZSO22WXTZvP7gjxb xna77dOF2xd5LDq16Lbdp3Y9dq/t7e07HFwcGIdvHLc6fun4drHF4o2Lh5zcnU44oSWsc5JztfMF 5x9cPF2CXFJdKl1uu4pdQ10rXa+6/uQ67Tbg7ute42Hhcdlj2rPV8/5SammFl51Xi9cTr6llsd4i 7xwfsY/C56yvn2+xb7Pv4+Xr/Yz9gv3N/G38q/2HFc6KMcW44pnitYKlebQxLaGl9ELamV5GM3Qg HUJvpaPoJDqd3kfr6Er6r7SePkv30UP0MD1Gj9MT9E/0a/pXGjE8xogxZ6wYG8aR8WD8mFXMOmYz s41RMgmMhslk9jPFTDlzlDnJtDBnmb5pGzG30EgOKO6y23TpkvugQP6gwJvxovFRwtQg4kx0/7mO M/19qs6Iz2OitlN48M/gzR00QkVv3UNyOL79z+HxsWu8ezMbUQUldmUdoIvTeQAEWAKBp+D14M86 cEDt901gepL8VtMcFaVN3kkVp+qRae1KEV4GF+f+72MxRI8BOcYrZXP5bAycIZYK6oDEXgkOjWGe gmaIxmhBEorGEPaRs0BQHIC9FGQiErP5Y5vMRe9+uAHYR84rAbKDKGLmIicwIyzWtbBTeknzC0U9 2F16DrM+q8fvwQk4TOD3r8S3Z4SQLkF7Uwoo/AV4suEE2AjVtbH1TjWiO2EKoXehXRgyIpEZYMGj sRQqFeL3wyrDmmPAIq1kHnITfp+sz71ZJHIY+kX4pvbtGbAjQbzkPDIYoiBBiL94mf31giqlCG1O IXJLFQ2j5PX+491cV+HXL/vgaF/GAMR1fHVOAnNAAJtbb4ERhLXid3LxntxJ+Y9ExzXYePd8aUjW J58i2Z8267qOU8ioiVh1ft042A1D4MNbcRc8HZEYCRFFcRhsYm8RKkFe/oG8AllewYYIL2nY7pqa DBn+MPdIelZNhDQIOfmjlYpr4SPg/DcI+e2AjMOK6qoOHpO2fVdV0yIrOYh+mZ7GhgQc4sQuIq7e htVXKypzCo5QRwqO7UsiV6xBLn4JmfWnuSLWZ7+xvwNPGuBAq+Q6yMq49Be+wbPY26w3oRVeyK85 GE1+vmNTgpJCThCP3Tjx5Ntx8mLkCJJQeI67rRKZba+Nag+R4VlBCWjuWmRJIpMXIS/f3r/c0knh 5yI7ureNSWuvlH/XLSsp6b556FB69bzde9OzNdKIxLMXI2U3nup0Qz/UNlVV9JaKGoR41vQ95En0 1DcMtlD9K7s2DDAdW6zSUxIyEqXOgWB5U4bngBh+JPr1VY2X21ZsCd2ZnbKf0jZvGRkguT8DLEwg L/CS3IO1q2/iwXj9K2C5hz7YAtgNkJAXkq8HbItJCl/bl62nqstKyqRHyvft3bg8VJ0h43DkP/mO 1wcYH65OfkaEaVAkmoN6SV89ioc9yJzSCxdf3TIKjSRcGe55cIn6DwIBHNOE/ImhRojkXkIvOa6G eLQHzCm18FXw+VWokURX1uzw2ci1/Cs2EGnTL/7zUbrkEitFu+rwVLwIvmZTuDyvfdOi7agRna6q aKkg67Ja48Kqwzb4UAcOY/mPew4PkEfzOiPVqWnqTT0FxV5UXhHW6XVqjJHmJOZGK/7R9zxCVpwX uiNZvzPLSrlHp9lLJrRk117JuTb0iCovwJxVlWFkWnVce1vdqVNdsRUHnlPlZe2ZJUVdIVbJxxsK q6RNJ+qb7njuXN4rE9P1aaCa4EH+BB/y4TyBlJ6gRKoJUIFyAilB5SngxlQ+ePHA9Sb/Mgok/s8e AwMiXg8U8qELughUiERQOCPFjTteNyj43f91xImnsZK0ya3pPC3c48PQ5GrCXYByf9+KPRWIc/ST VnpeA3iANXjwYRQ0RND+NQVpVHpBbky0NDxrGGxlkCl8oAPJSH99CHKi0DlkQqBtP6OFYAHyx+AL gZCHTEG0wA5JbFEZJdY1TC5J58F6cOCz6xsIh/1NIzJ2JEuIyhAP+0J4pK2tukbaqduhkU0TwnVF SiQ6RGlZE6FYB1bsOhDwYBCs+awGYgitYLV6/z4bKXISwDJwwbhBwdPdaSZhCZrdvg7ZBCP70HRK L3h49vpfTkrfHbNXI2NkhuahZf+is1qDoriysDhM9xDjJM5Nx9hT250CWd9mEBahAmR0xUUEfLtQ rApBMQiD0AqM8lhfvGcGDAnKS0QbEBjkIcjb12r5QCKIoq4aXYmGXaPJKuvp2TuV2jtirNTW7o+u 7j7d957zfeee7xy8gN8uudHK1B7p2j0VEG3SAoX6L0jlzNHi4xf71ejhDfOG5RpPITSF30mj/lvx MCkcT2Fd/hgbygXqns1XR+u2bwm4HnuXAJxIKufjobBBr2M8ethW1SzeZkd+3zoLv+PjEhBLEEMB loFM8k1SHWohaXZCekkDBYzk+yn9CX6XxOM9DzsqsBwMNGonzDnTSA9Tr4CMxp9/iDdREAGdciOl 3HtJ2gfITnK4I4MZUgcDtdRJQHI8RM3EzwYzbmV8o5tyZvvZkCDWc0lCFBew8tFidZg+euvKvpjb 4P8SxsPkZ8uvrBd5v6bA/Zp8hTKtCn5uh/Iku2pwAQ5my6QtlkUMPqPDjng19mfxPuBXPga/JvA5 C1ps37Q4dMe+3du4NggA5dkfyxV4mtXEeOUGBAWmXIYQc8FfDAbuQGGpoUTdX/IZnsorDydKDfAb u1IpTCbFWzwYqxu1AQtykXpY0ZNbqYYICv/J2iD/BzlsdZYPjqmqYSIeT9qpJ/B4CkxAI+gGaalD TIv5RPfN4kXBy8hQGMPtzsfvXhhhn8F4Brv5uc/16A0aCufRiF+ix0Zsx+LxP62AceD0/R2YNLJ0 4HenOPTdubJ7DQ9ZdON8xDCezaER7GCtZm4crq1p566tvxrmycbnaub56/oGOWVBIpS3x1fCz1Wq SphNeHFB3bVpDJA6dITV4M+SE82fd8F+m7DPGg7dw1qw39RfVmwwFXOou9hYlF9cEIxXYIfgaUkK mCaZmL/mXrl0uTgQh2xPD85K5vbmxGUkqxcn34Kp/Ng8AtPAW3UfvCejw/9nEgmDAXubfROxNxJ7 E7FvXG8TSiIVMH1s+dpr6CHqh0MtzC9a4XU918RVGOVF+3ftGlOKwgT5L4KCwnAA/Mj8r219Diba 1Ur5MqnhLmPlYIFELvkwbc3H2+Sf0ZLtpvR5NQyKYTuzZJBJ9ZITYzW4SgYKK+zHHt7uUXuXcSVL YJv8FtmA3MgbhxfIlQS4lN6gOg+To8Dbue4kzEA/wH5IZszGIwUl3AGxsrinVnHG3NLVy4Irnl8Y gz10zp9/cSj8VHnLgdNcd6Shhm3sMX11p2BeOIeRNtqV3WVINeg5lL8Yu9mANUZ2dYzxuC400iZ3 0KDvAEXj5k4wd8GUZhWM+x4m3Jbe60QPSG+eyaDT2Dk1yHeDOmqreBEmDt/sJhNCTVFCGF92kalM 3VUVqsacP9b68ORP+4GUYwbuUn5nT2GpwkjmgrSco8v61fDeNfh4FBbi6cDglXgDXoBnYAFz8A5e BxV3B6rr+vi04/K45WsSNGrycSKoSQb1wBIBmwkBr/B07OAagid4h+V1l5r4PjgoX0Qph3JF0DZL RKq/snjJLL4iE5qdXL/+Fd4mHfloK4UFa7tOmxq1Zu8UATaIdJQx1NTElpS0VA9ykEAVRdctiGO3 7MgJzOAEuE1bs2AX83fI/AlnypXluaJQB701UFkjiKqX4AYa8CTxalEslMJTpoZCCVezhlOwExuU Ng+PD99R0s5JBvsjBkPlKTVKvFex3Nc5IRyzPDZYHRgYopAONucNPHtAIDn2zC/ijDQ63noQ5JUg Y0GDw/JWcfiyQHVktWYvYa16Oig6c1U6pxzSd1kczHbd4Cu5izKLM8xm5npodd7qGK/iwXA+sjf9 6UUWvJthDvwWqAfYwe04J0JaHCXs3pMYF+/T7aLGkXgq1hDSl4EKe0AqfHDnyrc3eBt9wnHpZT0B +APpFl/DQhRT9CH0U5BfQMRCAwEszNWQpJk5fIFCpQLdnNmWHcRad9ORSbEBHIqBbOkbpiInR+xV g/YIjtLgva5LsX3onrIT/GsKa+FUPdTVv6bQHdwrgRJREmoosfDMW6CBMVkr0zmUJEj36ROwUU4S NyvAOX6G2l9/oI2HDPr5KR2edICvhCfxVAp+Pzh+lkEBKfTJsrxzoL4uYMcjBPE6601KuZkciPO/ cjhHBPooeo6+tTnszGr5tUMBrCLta4ow9rGQSoOqZKFnIS/CE4FK/TRlEX7fqEDPx7wQoa8KcKrg jhInvZQSJuvNYBAl2qxqBF84DZpIEUmWTNuI8VSg+jPrspeyjnRYss4Vr0gH43XQniCi6cyh0TcJ 4v87QTGYIx04BC8Ee+wLJh5Jj0BdXd/FA6LvHzVd/pJU6WSC7Wwn1Ip2/yLI0sFdZskVmbVffpF3 kZX09NV200kTJ+IRgW7L6iBAcQROhwi6r8PYZrM/FujWzJPZ/jYClkdnrN1HCHgs0mv3R+ZdYmEn pOOddFBk5lobMSO0EhfmihZKtAM5cSRRIrM6L8LUa3N0rcvQaSQbvhDojqzON4xuzFxjK6IXtHKW 2bJetDOB033bwm2kweFRgTqf3ZbzB9Z6ho7JXeW/NbmolKuuym5mz4WUJ8SGJ6zeeYi0uJkvgG6C JZzkRz+qM5zPG8P8OggHG9qvRSbJkGpMKcMXJOVH4AXaru7R/QoRtwr0YObB9O2sfs+euDgO63Cs HLbQf6s3nssjgT6xBdrytqhWp79B/po5CKarRPDHSfISfcGf09jkHVlB2eSH7+ix82sZJ6pGwR3F WVSQxMRSWL5ulQeepfZLKOjipRh6uNYwYKP3nwLd/toJarS50WWt2sehOEEaopXQM4ZitFWqhk9k /54jMv9hukqDojjTcKYm3U0SFw3tKPSs3caNeGRNqavBiBYRDxQIKFEwKPEWRjmHaxJOlaOHYRAE B+QYroEZh3FAjYISVBzUjSByGMsouoImRtf1wNp9e/KNtfs1MZX91VXdX/X3vMfzvM+7piSx4A4j BFDDTVqbiLGQwkM/Em0WIglUpCQHcqrSQhhHDLUuPXWpWKl0A7Wo8Ov6fkbYpaWgwDFMNJJQILwg tI58ck00HygGdZ8SKZ2YZJ+Hu79VWN5Kt1VMgmQDuaw4ST/ICB9iyVEJ6xwnCKMwTLYX1Q2W4Kv3 Kqmh7NI9gQyyqSn0XPAiULiSLKvgV9k4us0RTa2JyQrMYsfa3u5qkVhxz/8HVkoFN7u7DKa2oBXI fUE2ykBeyCsbMkbAvQVWwFTO8jbagBaiKSga7YZZaDreVrbBLJgOuyEa701T0AZujK9mK9ismK/P cVcvxvr6FGMeMZCrSlTaIQYCKHDNP5ff3ex0p003YMVKh3zLPVls8OghJXUhx8x7MI4A6ou09Iz9 bFaOOi/0gBMemXnCj7La/LKyY/K7zbsQiSZ8FY3+pOVwEGgFBCVX40Bc3gRCq+g2ezR6R5adlJwd J6dV/sstP+3i4KMTL7Hr8mZ+R/smmhQ08RaaBQs3sdiYeg/ARo1O3tNR0tDPoef2k78nhKNV/58T fPZNWtixofVtE3SIGgWiS/cDL3oIYzYJT2XmQq3uovzOt1vd0aSQRDQ5jxP80A1ZRmp+VRqHR+Vx orNy1AzjGXoIlqCI4pU4E5hduWb1QjENi5N5nwO4E342UL+1GGxspGAHukbANtJ5Li4gY3axmpIB L1vw3tqj9ENBJcTIICqKUuXkpCZEb7Z4yulbKCgS/TkgTLMQvD7levcSPZFn41cz6Tkz0TjRJ9Lr gHiRzEUjjYmsOFhYVWNuUzyRg383Ngcg8bqkqOTQjBsEfcPjlKq2k+m5ePQ8vHsFUSurWJFUwn+b JJZG2IBDX2+UCpjWywrjtfcZoZ7qyx3NqUYLnEykGsIIx1OSR2GEiayGBaOF/QedHPWUR7zaW+x1 O+511Xd2iUHyL/gb3GyV2teJUhOrJIdzSxUBDLpE+anRHFyLDzXAdrEwIlL1WsFvemDLblB7MGiE Qm81RJzexQb1PM5ulV8Z0Xd2cKfajjy8zMAgda1Od7EY16tAJJSkwr7szR0KnHDelLuTSc6M25+A TRa6iyZDH7HPkHxKzxyv01wVGf1QSZ3OKucbAqHE8U9XzFaV8I9aW5n+4iE3Z/h3UZL9Y4OL/tdg vOIQokP9VSH+2ldJHlNb87YzSbmZ/D4WSdEvhJqcCsNEtv5AfSlzzJQ/JvI9SqpdrcssS7R+5Ire QZfwIfQevCZydbxOx7QYtc3iqbNY8rMP76vcBBGOZ65GEnyFCOIQCUscEaJ8bBaelbbU1lsL3MZ6 sjpJmCCG6SW1rxCxFCjJVt6YF8nEajSYQfPZ2TCbyKjii8oYU7XmshjjM3yBulJZEwmhqNUVLUdx 4WGKHEUOtlsFBiqiIOygldHr6u6BlD1+7gX6hDicoovbx8TGqEN4ccwYqBhtijb4LvKFZleYD0p9 48/FTiKaMdU3i6of+KasZ/kW9U4mdu/6rEwxL5+jcZBKHKhIMZQzxtKiPozmgZI6x9dvLdwPfui+ K5pBLYpXrxLF8zme84cStfcY8KfgC+iubjId1OOoqzVWYdQqMQqjUrszZMviyBBsld7KR/EFwng7 4VrhqKGS0HbCSFadM969WWc5rNHA0kKHy2vCNUW4hYdkL5plsWstkt5XUui0L5ah9NfXId3iSYbm 1TRxdhfqsk5nY6+Szg5Cm2THPlUJQ1IIV8kekSjDHkp8TP7xD/jklbQJzZJBuv06St9zlbTpMtdy r12oPZrkL1lP0nkNdAsSyQ1htRQzp1uGxcmAzbSBeEiiVYKE8MQPh4RwRu93SDQCLxV49L6sw8F/ KeIEARZiGXugSXbpv+4D/nQLvRoy7T54IQiOQoQvcmFCTJ/fONN89PzVsIoYNiNHnSNPzzpcahvq Muo557RuvwFhYpOLAdwRDW7gBCy9k7YIUd2yffsInufzcuWJGn0RB0eox/NP4wJN8A/w9+nUlJ4v P17FnogqrmEq6qqbfziyeyPrTdEJaNpWRO/4C+P1fWR7fX9hTw8bU1S8rV/e1lJvMXIopEuWkpYQ q5CHpzabR56Z6go557lpTcL0TvCplwwCBx4wQ1ppnyprztLnbmYcr0qp2zbiqzPtGWY5fHodJgIN k71fIGpV+K6vv+GgFAVTEIz6ZLUl5S1n5CNFiFmL5kVsDFyffs6IV84tab2Cm1ligA/ABSZIhbkg kcXGx0UHyZcGDMHUtkMw/sfyhv1RGzShtuIrmu5Bj5YVc9C0AGzaxg9/ABNvXzvZc0bEaEusE961 YZQ4VzMxSo7+jk4VzKdlQVq1qZERBtHeeOpibk1eMIP8qIZ4RXOgfM7MRcgbH0Tujzzu3TQajzez vhSd+n1lST5MKHfCH0IfyTJ3rw3z1MCkS0+P/DRgqw3IY0XUgxDYAgtE4BxelsZLYRFYZcAeq22x likTi9jiKE1IfqTTKzRPlqCK2LJW/tfEl/d5DgrJTj4dW3tvOaLmzsHrldfLZS/udDX98necjF5N vTClFTaZJQPAdYGzFG8F5nrSV/tNcR8DvSOtC8CZaszvaC+t4lPY1MSUWCa5UnHqZF2jte8zcwBa k4fcZrNBW7rQMBmcwCtyMdTtTeAM44aNEHlhv9nF+GAJnqmu8DY2xvLdt+knn9GjmUKSME12AU2i 6CeZFTsUReFyNMVniefy9g0/xHJqin782daMZTv9mRBLalsKi1/8j+5qD2rqSuMik1zGrbRNjAs3 zr2rM1aqbbUrilYptT5Quy0oFAQkgAEjEIUmPJLImwCBmxCQNwTyuIlgAFFREIG6KF3pKj5rt7hq p1an1nW1zrrzXfYws3tu6M50p7N/ZDLJOff7fef3+873/e7TDyLKFQflZMTtA/AavA5+R/GXNyIa Yo2U+EXRTqNgk/EzYy957IS14ynD1HdRtxw95yfISwe7ihso/Pj7M1GS8515ii1IxMh1S0yX7fXN LhuN8R3wb8mfa65NTDJrZLsNm/8Qrr90nfJdhYkRXeVL8DrmmwLam3OzklhmwEKDkYC5G92R0YnZ EXEU9KJINXGqtMWAa/MIEaurUOgpNZSxRHyNoctBgpWoHxjpHzNGZlConNifr0sz4PVCAncKjPEu +zWsFF2ClegNXECPoY6VJJtL7W6Se42Pe1LfqpeR6BwRpzMoSvBzpYR4FYrmpvF1TuxOHRro7Rkc SD2eKEtTJFF8h0lwc//0hNwN8wdx1CU46kto5pIkSKYWHsdtPpLETi+pNFVuOGRso1odHU7Spu3Z l5SrzNg0lXEBPjJCwDglDkBvccCjuDHKcYxyAKOk8yg8Nb93QATrdYOnpYGPnZYlHNY3VuaSpYXY mlNoAVog4DajMDUxzOwtojEx6lKFnM+fJeKOVNQPkiAkHOwTRAoa85o1ReThDEM+Xi5giVK9saWY RlFgc7nHhu3t/p2ODnP/ER8PX9M+rNdVjOrhqdjdRXMP0W41MWL6GaRoFgRb8U88AipY0c1Z/fjP gkXikekLrCTGyLidJJgJ7K14JXfJMsJlVHee6sIqaVBCmDqfrhSKR26hCDXRVeEyRPMCxGaXp5Xh 2HqWSDbrsUD4WStR1z86cIHZk85Lm8Uo4wyzZ0ipLrF389LXnRk9M8ZEK/l1NaOMrcTrJcTP1YWT uz2bmPgs14ery8S4WU9a33jSWpuIU6FwKmc9qfSXNZd6auFXNYb3/98qy3dzwXzTWAbv4j4KH4BW AsKaZ7cnLOHoHSQuXbttA/MPmEOhZQvRwgfYpNCw6CHMxZ2ffvsl+i2iAxGBJFh1lGSDkAvcvHGc 9td411oI8JjZNHgmaTl18exXNcgrKAKPovWR2RMMNYX6JXtNyvo7JCwm0no7My9KXzx6BOthbcD1 oA0HZWk6nuS7k/zJhsrq8lLImUpiX3FxPH8yF8HjsbBhjFva7dULb2A0LPqTv0tMul1R0h0Z12Dh /SZ45f6QTS6nIWrmlERxRFM9THI/5BHBEYJuRbIzWoqWv49eR/NQyMMPn3eNNJ49TSOa2Ko1RBZj q2DFwzKBYWEclq75Dh/pPlahGYZZySfVha0TpLgLdhFfDdpbKfFEd1X4F9LRltMuNm8sdKcsTJnD p958B+1SE8cq2PIYXpSY7Ip0vj46cNzG/F5uXY/I6cx6DtTfEu3ih/AY7khgaTZRaqgo1Gr22fdi 871ye/hqGr0DJbUryYM5ihjecXurXx4tozPQeqfQ2lBb11h/7dCo9PHlPz2hscjrUEHWC9Ld6eqj xA/HhxK32PgWXngT/jXIT0pv+ALfxbchWCUMXS5LiJL5ZJ5H3xA5RnMQzJE+6rs+YKNVjYKcIp3y kFRuPN1Gw9iPmOn8K0oHR7GiK/8tRvzu2DsgkRmL2k+RMIPi1USvp3Hg96A+QqNRqVKkkVUDnTT8 gMLVxGl9XaGcxC+2W3q3vbg6dNrZxc80zXhHixFebfbxPZLDRbMiG5eMVsAK3gFzWr5lrFALnVXH mHSyoCJPr6M2o50bIUFQ4mCqzaTDauypplhUrSacFTVMU1Zt4bGP7Z/CK2jEzyWEQO531tEWE8v7 WU90L+46SL2no/m4UrWw02CtTCez96DfZIbg+6OdSoKFNtJmN7lMOGiBmmANjUx9Tk1hbW5DaigK 8YsBMvUvNtLFmlr4HSo14Sqv0bt2QsDMPD9WiOfZRUGN8Dm6KHAIYSW31DLYYuow+/vi+rHnwHpW 1MQpZ9IgGDuKjeKfOA0rKTCXVpc0owDQ+Imf/gSidgfb1Gn2Z9FGPCwMTVU5ZD7DbHqLyuuImLJg w2RmZ497tKKuxPIZLEAxfvjyhRiqEsp91BDMEjpjGuMkrRNTHQ7KHWvJqc/zadLUHi4jD2dVZFfx 3QAXXtI4d48Vtf2C6qz/oTqvvKBMR4WiyM3wsaDEXuRqINmjRg8rv6Z62E8bJcjWq8JSpYXlTTW0 ubqmnmwv6pGFle3JTz8af+VH2zj4j1LwJre4Y9RismM58JXq5hZ3e52xe3PrIFCSIdQrM3ZE5qQW JTH7jHCYW+bnmiEIPVoicAld4HWOgXlGVDAT4KfixPgAtWhz0/SjJi+QvPQGSaoEzZ/KBX+qiXiv RdWPHUkIcVPXv7ydMhFP2y39N/k/bjhP3W3FO5B/cC7ypVEosSNXGaihHmisyh2k70zIrB+f/N57 UiP5fjp2tfAXMIEvvcfQZgn4T1nBl4ZQYtLqftBBBXbkuidJ/BPmB1uRP1VI3M13yreRKITYYpE/ 1WJLslyrk2/h/9iqSn4vD89eMWyCwNXfirq4feJEsY2Lg+/w+DyQpdovl2amWNv205aU5NZU6XZF QlI23bdVcLyNPTEoHTqh03bT2p7uvBPSL3sGzxyjPWOci5/ZnsN1Q7DoHgSjjRAszhSvAjO3Bsc8 pzgRtzdFERd/MvnccF//WUpseBMF4QUVqpdpg8iPeg58fr7n+OVvZe0qqKd8868m53CfuktzO3NF f4TFYidkwwJJ7smiz8fJ7hpY9FeLs/AgZSBgDkRI5EJxfQJ6VSBOrtHkVmukaC56bT3agIiLH95S 0nvQUkG/8Bz4C8TG8jZLZbu050Htsxu0tl2QpclIC5OmZzaz2fQ90AnyGy1lbVLzl8x/aK/WoKbO NEyaTcJ22Vg5xq3n2O/orrWKY13s2rEqWov1ii6ggAjIXZQ7CAEMhHANSQiBcE24hyAEAkwEhRAR UURQd1VcdMvq1BtOXcuO3W59D/PhzB50Ozud6c7oj50z5/vxzfe8z/vjfZ/3ea/2xLdG1LKbBTji +abnVlh2DTpMjg3tMP8fg7Aw30Bk2jELmF+KMJ8v1x+FLU2kucLS16s6lokUgbxQY2LHYF2HpVL1 nB1Yq/3xu5vCteyHNu6e5lcHNHkU+ttr0mVFCdRy+fZ412vZteOmnoZqmjgnOzDSkcMuCYIKmDdR Qifxg2SSuC1UZrS6/iBd1ak91UY2qU4qahGbAHD4+GucL9KVWvpO1Z1Ir0EJudIgL+rEkbJuWjib VCaecU/h4E1MHheaZ7aJZve+dOdd4jN7Ztx5QhXryQe+GoDRZg7shYVcxhv6RAOYK+j8E3AguMbc pq5WL2rGwQmC04ouZRiZcCIm5Shai7fyFHwveMcFUDPZVFs6gprxUIKgT9GUpIuDhbj0/RW+8B6/ QszzxJQvUIcEnx1R7M5jp9fXRsGekqPqe+RZoAYw9WeBpoLdB9eYmGoryEwcFdjdAYeHL7gTDBKB PV8668RzLghPOk5lZpVq6apadTPZEa+PF0dKD0c2BN6CxcPwO/iwFlU8VI6UgsAehFYsnOJ3qoB7 ra5IqkB5aSliMq45tbXV0NKuz7vqhJ2j8IGtmQg7sP30vgFKDJA8dzoO3w5m5etXE3+H+VvvH7lD /POV4V8hF40G93ta2M5lb/oKvykCPjvPDHcfk9au5h5EfG9n1WXk0hnBkigyoTXarLfpB09G3MCC LTt913vYwgYCkULBIxhZSJGTHM8jXaxRIFyGhgN49ZKa9BAyPCV6PyL+9bmH1FBC662aU2RjsjnQ P/1w2vb7kWOIzeHF5ZEbNMF8jo3wVNRnKa/tf/iJQo0sYcWyeDIxIzIkKtrYFId2Xkyu7yOFILwH dfc4nY9A+4jL/BqeiFy99m519Rq7dXNo7NbE0N4v0exHOE50yePZNE/c1iuxUrbe6oY2+tnKS5dW TvMMrbpeG2mTnBa3oelpj4urVvEaooN1vlRAYIY4ml71zGP/9EqeOFYS6Ef66YIN0Yg1uMwK6Fal sPZKNCch7JxbwXZ1za2T4GAgzyS2hoYejw1CyqQW7FDjai8EBtbhdfCIRbRf3wFuD+YOoofYCYdm drBA7xjM240dSZ/WvX+xdpkGrwRUx6HMfEU+Jc0tr7x4d7iljia+gMrGN3wr7GLmORpAi7WMN9aC lmggzkPaCIuWVVVlllOlmuIq0++/i++hTZYHL1rJUlWJVJadLZUgHIjX8+QCophZjje8+XtWCVlK zjnQcqH8LXj+g2thcXeYxSyuQiqtzKJy5PnSmCcfngyhY8LXLYklc1R5VRVlZVXVCAJhPU/z2pd/ 0FuZAmGmV3vDIhDh91hHNMmYm0ThhbL6LpLoZxYLiMl87125PtRSPojU4/cRcbe3IjWblmdnHif9 z+bqikcLLz/BG1QZOFqO1+9SIs/AYfyA7yMuiMhnR7V8zrgr55bDx2yo7/kmjVRM4wuC48rYAPlr 2/46E/A1c8Z/3D/ZFDILeeFFhWfKSeaHVIF/DK9txzaVnMKe6ZhcpaD/Jwkg/FiQqowKz0c5St5c fOw+5wvQGH+k8M69zspcCcqRpmWQqZXpZQokhF1THBVTwIWmXzgzBVMCIeNZD8kpHMhu5oIOk6Ji WKb5rnpYP7hIXaK3FJElfxwtAi4aNwTbqPbahrYqeY9/cMqxrE20AuxsxZdJW6BGGpwRmYB8esvY 5i3ZmGU5SPmq/HKT9LEd51Vd2sc0Xu6ljCJzrGuKsTMqxst4wm9q4VEtpLC8OQYu48SsErXV1ba3 JdfERAaEKdzoZ72t/aQ5sTEqOSYjDB08LVlCphXyQgK6w6nA3AhpbL3YRJ8xdY9TSpfEkFi/du/G oEJXe6Vb6OkQKiZFHCvVRvTSFmt3D1XLx3bBMm8ytE3a0G5sNCNbYPO3pOKKNcxMtRpqWtrT66O8 JKGFm2l4Z+hsWZmXDd4hJ+vD+ijh7FIoBBdOD7hwe+A+W2v+XUds/ZYumzX8lL9fROhhJFyC9xmZ zUZ4aeSopoDzdOApF6wztGjg5VewxcgP0cSq5Q32BUaVroNkGEGHSldkRJqGVrVVY2/E5wXYabs7 prHj+B9gAY0nBcdUGQWJSC4+pgiV2yeCq2A1Ey86UO11AQQkvNvZM1HN2pEBOARmTieYuZ2sdjnY bbq6787k6OjkX/dd2bRlj9tmNGczdsIjVkDWOU6C247rhDvR8C3eyb49bwLeNXAkB2PHvgiIiPFx s0paUGWxupiq0mZl7t/gGZfKupQfwbo58INXEQ4QBXDhjUMQDbgy+U3pWLH7eTpg/h90c1J38qdS d/ttpIQozoINb6E88IOUrSLW68H61/+C+HvjP1dNDnbwYOFb3LOR01rgjFlmgvS2um5H7TNwbTZN w5fGsWnYZiRu3ycc7ZgbM94iP3682GfPGso/Va9Po4mP7XRpEn0QtQ07bMMffXwrhLUaPeA8QbPv 9coqRTWSGZsUFVTZBXVXL61WzIpefsCz8VlcNHNQdHMIlp6tqMzIq0E1uaUKTap9UZpKJSNXe2Lu Lh/VYB0izgcxU/iSCNv9La4fiD5wvmlQPV+ydtmneCGaPioa7IfPblb25270DsFOn/qqzjUiYkg2 G3SaleSpVAs4WmHtjTnEbz9ZshxNB4suDsC66/8FKG1GtsYDupg81kRfgJXx4LKi3Qy/IcyggnJR pCIpR4IyExPSfaP/zXe1RkV1ndGM470Xm4ot14s6V+8tJvFRsxQEFGujURBTRRAIvggoD0FeAwyP 4Q0jjzDMjCggIsiMwwzyHgZ5CQMCjY8IJr5atTUhKwGrbRCXqfW75NC1ekabH12r7Z/za5/vnHX2 Pt+3t82+6NDA3RLkDBvzmsGt6UWXKa37gDw0dz93yFwSJ4k4WHz8g/zJbg7o+y0TksqSsyX4/ntv 44CD3XiEOTDojRvvs5ixG8cfSzDCHlE5HBdDiWBk0DJwIqry5NWp7NG8uOzk6ixjFg/LnYmfkN9a kWZhljFU15xukLTHlqcr0pSJyRxahpyIz8g3OA+REh6LoRlXvEKiBeBBrCORLfLAAJj77HWxXqA/ +JNdpiCy2od6oQ9fr1Zd09jCnlWpUgb5xhyioKa+oJadrHtiquCPkBmFipgINkelOpPAh9USpYqY aim7Ls3pWIE1hQg37onUMC6Gb2Z+yaBxdxh/c5MH38lF1b1iuIBdRmx+lv9G1jH3WkMRf5h0UF/x e8pOWUafl70u0Ab2oh+AFv8gTDMybViPuaHR1B7XdCxEHibj/g2wUwI9DvQieliJUTjE6DDuAsZJ MS4V47ARisDK/q/7DRaYZxFdt67i6zPzGZ+BoKtXLf3XrgYO+PoeCtzLwSb7mMTEqPD0dr1ea+5o vRAf+7rzSbsedokg6KkYbNYwlfmEprxMU8XW6/JkoUGq3KTMsrI0PjOCyOzqUJ5hO6bKvxoIP38g J19ZrOAbxogQ8ifqcoRdYtjzv6mDv038H1bRttuix9+IYX0LkxRzODhY4nk3u7PtxgWLnks5SyhS chTJbJistt9YdbFUy/+HDCZmPmb8SDR3FZo7TfiTYBXCExL/9tfD+8es18P7x6zH1taiwhEK9J25 LVDXc8yUorcTPMAF1tUBaaSPDsOUvTBKdkEkkUzmHPGIieVCgkPlDqzPca2JpwOG4VMKp7SKfTWr bOrgL8lkPFqoUKB5eTagprSqyq/Bo3qrk5YzQtA/bUnaMJxCDSlNhbGSHHl0VgKHomaX7EJvH1dG FizBh8kglKKbho1UhoaILo0ubZXUnqw4reOew14C/JAX6Z6dtq2Y2wx3GXCFHqIM9eCHei44dENq nV3Jsw2P73xPP4RewYcpLCSUSqWqmFWoKkt5cKSu+BrdN4RGHg1tV5WZT9dVclr5ySpJRfUZw6Wy lDgujKKfOiVvTNojOdSV3lLdp7nYzWWWnpT1sY2Gs7paHjFtjKIgKzOFTVXoa4fGaitP8LY6/HbN M28Z7V7CBjphxg7kjJRERJC/G1rDfpRSbuGhn4IFD4jPKbRgKwHzqIlm9Z0TnBG9kFGXiruUv5Og bOo3hwhv6qsBgjYjP8o7rti/gKMTZMJ9TM6itNaZxdZBvQNewQ7xzLaZFOYg6bWWaN7nVfMRiwKQ K9aLFM0fXPm1F++K7IhB8u7fiZjh0Yy7LITAangPIsAuYHrT5/zsvNkYJvVWyf1uCawwgwf8arTr WMAFThfMaP3LPL0kLoUoF231DOkYklkHQ1FLggkut0KDKanFTg9boBXWwZo6IOppeZ4QC8cYuj0P LVT5Obi4NIAe5ukgElynVb6OnHAKXWISSIxDzjvfz1jD7lTVGXk4QcHCotO7q5zfSCUJzcmPQG+X 2ICGMtRoroC7Yfvaaq4egmYdycIYjSaGxydooqM1uSy6th8VvY/SYQnubcHac2qNnsfl1XWN6m5W 2I5VcEdw0MGJ86LaqelnYtgkuDKHCy0Pn5xp7eiojF63pSjwMC+fO3n15qNx71FXV28vt81Xd03y tvezR33vgI8ZHFvsWuFdRMNinD05bO7n05kz2FMxMnlUyHYWiVXwsz4eBxwKtpUj8dAmdnd4UkIi fz41rmk1S8tXfui387BJ3niprraT75EWGyX6tjONj1T7pdxmiragHX6u8e9IPHsiH3x7baCtjTt1 iqAzN/bfUpnZ8S9bJ0d42jLrEMPEStNL0tjg/N6GR2MNv9did29mxlR/vTVUFbmei6ZwDMTe38kg uo1NP5QbmPDSfH2zRPgF+jiJ6iioLgiWoH4qMKM48jh2+flv8DM2BtGXVnyo8C4z9YgYpH69mYBU 5JdEDWg+yeOxBte7EwepyXsEklNJeZFh1r0GKlzR3MjbZjcLHzSLjLASnGClGNzhHUZJltSrmpok QJ6c/mObLi20ksNC28wEkT4riBppZEU4i3gXRCFmS7PHSDC/FS0k+snRl0RGk1nRycLSSZgDS8aj 7gb08F7LGQ2plqljIyWIzt/gGS43XFRwmJemuHtWXjY0YvG9Bw6wFGiwpS8Le8HEjFDNas3DG+wV jfeKEzyd8xI5MdFSaZQXi0Sfgu1NDQ8a3PWUQf9Aq1jvyPjUBL4mM7bVjUVLnNEctJSnL6P5D9HP weG79uZzOi6juj72z+yry38YNPGzizuZ3QrP/cFR1VjQW/QtluHaiDWcrWOuKdkAL9qgosHuDvDX R2pg2XJYQadr7cFPGCeN6tKhEZbO6GqSrfYvjs6T8/RgmiKjSMpGUV8Ut6eitRLkkBF7JFelOpvK ZUcR+ed1BQZ2/OU9sAexz2dIYuI1FJ0xeW5s4JFk5JMp5IRsXH+7nJt1ow5kF0YU4tH0HBp0wjK5 6NX3YqgHC7O7sKaTh8d5FHLbRaRS5Xp92WnWqErM4lEidVSZ/KGak+MObbsFxiZEQsCEWAiAt5gJ 6J1VOwsupK0j2pMKAROCvVz0BU6Si6xJMt4a/niEyGx5dE4aGx+rG+HhJsL9g0I20b4hkiBtzECX tqWvN6H3X6xXfVRT5xlfTsi9YGnWkl6nudvNpj1W24ONY6A2Tj2S07UTFKkhCBcUgYDAqA0KQUBR 5DOJWPkQiEFIQEAKKR9SPsrgDOwZtkxKrWcVnByCrWsdrqunz81503VvboirOztn/rFzT97nl/c+ 773v+zy/5+MWXWWMRlGWtf34AN192dzRLEto6DreRw9bLra2y6zkqaKC0gKDd64xs/ay1FV+mizg sAqsFhDeAy88tsI4rrLljp9TA0SPOT25Qmaxo38GWIjOigutPfQAmiDiDcWRxcwRiLCQ6nJDeY+U CwymagjMx0GREWmJeGOx+rH7UEe2n6sdNDIWtIxEL6EraBVcESHZEaL1UlZqrQydJPcV5bAleM1K C8meKTINSyHaSIpv4nTeCe8NQmOHtsnvPgRBFeyQZHI+nA+FCNASjWVlTR/SsN2CDslRQcBO5BV9 Ckc75AFBOoXLPyckfegEqclKD2EkmVqYIuFsBfwI5BAihfVy2IHeYdBVQpKuJbuL3yvdJUVJclL8 D/2MMhN6Lg5fh5Ysv0++4k7YJe9zHzuUlCTXGfpdmOgqwe10hImctPNnT+pwHCYdaC2VQxzMLix8 lQ48S9ybF306qe83Sz9XNMS/nBhw6DhjJYatneV19GT17mPKLVtWrZblgQVzRW+HnXYBFNqFUAiI QgkBkIBW22E1JNhRArwQQKAE5xmKM9idBkKcpG+CtZ0w1vmwSfAAm+wV2C40LYf5JuLVSp1xVjpG wgrD7w0f2rxn+qunO6V3DjxA2czr54nZeuNUFS6F81pytOhyyUapcxf5Rt7xE6eY00WlZVEF3rg9 VlONhpqaDvq2LRER6JlYXOmMMmwx8EfPZy5OgtgVDX7ffgUll4C+JzE7wsGfgho1Kdm2OzhwTXig 92sQSErMv/orKfn1fC8puThJIulyROPssBK2iozE2/A9JYl5zM6rntzO4q1p4D9vnwd/ASSC/3Nz uGdNxG0qtkwAiT+6lFCO/x3sTO7rtnV19SbZ4uOSk+Pw55jzl16u+SQ8343nO/H8oThG7NymgzbM lzbBpF04qcOR2hZAgNyLl2Kk59bYIMUmGO+FA71CYLnfUuGxw+Pj/a7fvvDw2H3hsiSvmWvXZmZC rikUISEKxbWQGRkO87gG2PYHbtk4/MYquIkjPQjWCiEFFqna7rH+G2eRYOMbJejZzW+mNPTkMJ+h Hoo1plXeksIvyJSOlsNj9Nd378JmCFo7tVHxu9iUXFkpdKCIDMJ2ur6YlX4XRx48eTLmNK4azeQP vEPaYGHIDyK/jLoJvryDTPmcw0XsmPzHLO5YR9VVWTq76KGGt5L3RuSmnZKdJLHy+zmzWoU0OuVY KhOv+2AvnVmoy8uSqhbKKsHn1o07/W/2RZuYcuzffGtNs2lAOsZaQ7fui0jUMY7nnWFuIijyf8gE U76LCop8FxdM+f9JBj7BzoD5ugBCMPtHuTWPQuhlYvGLJ42gB7oR8K3ON8O6RtjS+O2IX/M0yGfu zwE9LRkZ5ZbpKIjCrZkcj9FoHWxAUfh6Eaf7aBQFLyI8Lxvxwn99cR+yCZvdFztsA76ewml5M9qE fBGD5DKk4I5Sg6VlxYlSVEFqDMU4o2XDdjPOaIbyd6UP3yUld0ZfGW0JvEzPVhNZ9W+1Z3Tsub1i yNTeOyi9HtEayiAVAX5HKRtha8oKi8k9wMqSCVwqEu2CdziDkKcyT2R3CwDpWf/uAm5DNsWXa4X+ G5zhXH3AHy+EofXMDvgb1aVpY817S0tWtGekVqZ4WgG0fB6J8El+uvANHICgXYuKD2RfDEa1bYhR te6piS5fGaPtLxjQXUlbiXzChtJE4q0mLl0wxKULIQPeplAwCp4Ixe2HEoKRcmICKd04dALfUSKM Q0NFLgc2uFmnxKyTTNm4eUoy91/INfW/uHW4L8LMSOZa6h4nFu9cgQU4y5cjgubpW1/DsXr48bTw /+VVeAkyqMgjCfG76fUpsw8NsgeG7o9v09OX2LgqWf0nRGXhuZyzTOVhbZWaRoo9SBSEmLuvg2Sw txZ/BF44V3XGcN706QrxTQgDzUcQ4QFqD2A9QIXBa6D+CGI9M5EYJOj/BPvFF2EHaKbw6iWg9gDW A1RiVN0CmhtYZwmoPYD1ANcb1KD5DD8YtxYZoLmFtT1I/Qixj5DqEYoUy8ELNH+BePwMLWjm+JPw QO0BrAe43qOB1AVeJxU0C/w2FaC5i5f/WX8fz7tGNT+y/Kjix1h+jBSj/VP6RXxstH9C/3fXiXip XpLsklThZvqQHkqxwhJQewDrASrXvvW4u40U39GDEKvyQu0WrFuo3CLSZSc9kHiT8od68MHKbqle kuyS5PWfdj/raX47Y3oQ42W6esemOnTsPAEN55xHz5B5tVxEFcTWeqN0A5dRAc/ofZiG4OyffO/r A7KnDL5iruQ5B039awBBWCM5CmVuZHN0cmVhbQ1lbmRvYmoNNTEgMCBvYmoNPDwgL0ZpbHRlciAv RmxhdGVEZWNvZGUgL0xlbmd0aCAzMjIgL1N1YnR5cGUgL1R5cGUxQyA+PiANc3RyZWFtDQpIiWJk YGFiYGRk5PdwdPPx9dJ2zi8tykwtAgnZ/ZBm+CHD+EOW6Ycs8w9xlh4ext8lPMz7eVh+yPKI5f/u +8nxcyer3ALG/93dEJKH/XsR//dywUPfjwoxMDMycpTVGhiY6BkYGDjnF1QWZaZnlChoJGsqGFpa WOoASUsDMGkIJo3ApDGYNAOT5mDSQsExJT8pVSG4srgkNbdYwTMvOb+oIL8osSQ1RU9BwTEnRyEI ZHKxQlBqcWpRGVAU5gkgYGQIALmEidmDj6/+0PePhxj3H/ohc4j5x77vuaKPg74r/Q75rfibxeS3 8m/Jt9rfDb7rvH77XVwupEtU3drpN9tvaZ/nd15cufdd4Lvp2t98oXJ8tTN/XJjxW3vm90cLfrt2 s31vmPSh+8/6XnZUcQ6YOOchrkPcP96IAAQYAI7Ei4YKZW5kc3RyZWFtDWVuZG9iag0xIDAgb2Jq DTw8IA0vVHlwZSAvUGFnZSANL1BhcmVudCAxOSAwIFIgDS9SZXNvdXJjZXMgMiAwIFIgDS9Db250 ZW50cyAzIDAgUiANL1RodW1iIDEwIDAgUiANL01lZGlhQm94IFsgMCAwIDYxMiA3OTIgXSANL0Ny b3BCb3ggWyAwIDAgNjEyIDc5MiBdIA0vUm90YXRlIDAgDT4+IA1lbmRvYmoNMiAwIG9iag08PCAN L1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gDS9Gb250IDw8IC9GMiAzOSAwIFIgL0YzIDM3IDAgUiAv RjYgNyAwIFIgPj4gDS9FeHRHU3RhdGUgPDwgL0dTMSA0OCAwIFIgPj4gDT4+IA1lbmRvYmoNMyAw IG9iag08PCAvTGVuZ3RoIDIxMDEgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSImk V8mS20YSvfMr8uaCQoRRWAldHJYlje2DrVAz5uKYA5ooNuDGwkEBTesD/AM++HsnlwK4dLdaEw5G gLVkZWbl8jLr7Xb17YcQNGz3Kx1CgD/8ywM/SMIEsiD3dYCDbbsK4G717b9uNNxZHG939DmuFHjb 33G41r5OYfvOLbzfrjTUsNps/BT5pbn2wzCCOIr9LIV14KcwmNV+9ZbER8+JT7Pcj1MRfy4oIUHI JAiCiDVxo+PqN/Wp6Lx17EeqlL/eQ8JItZ4O/UzBL/3orTNcMF6Ec/vG+8/255MJUj+NUAdkf33F NW+R9Oh0zTN1WIeQDq3nIanzwUv9UNUe0m3UYEf472TsWPcd/O0kp7PkMLyW/JsCW/VTU8LRwH3d NHAY+kNviwbeepn6DrmmqAjxWfP5RRtRL3rRWj/0na1LM5gSoOqP8ON2+xGQbaBKUzQWjvVYwVgZ EnzbmNaHD8Y0dXfn5WRNpjwWVs6VdQldPwIdFa22r0SaPtlFi2BmXI/C4bMXBr5Gl8T4HeF2GuHI 1+6M8daJn6MziQBg7KHuWKH9NE6DEQVvfv3+ow8iUlwSP+XCR8ETLuZw3npndmiNEgUUIwzktRC9 R5fdqIoCKUT1OrTT0VtvcEJBtFFQ9t03TDNCRRfCnYJ3HgyYrp/c2gUfvMeeIjGUCA3VILPWW5PM gmMEr3vt9pQEXgZtFPhJ/ihq/6YrL+GFJELhojnSfpC/aA+0f0lK3A5F3dmxH1qwfWvEa/2BdLSz 4ddn0XZteRcH+hQH2sXBz946R//2XeEl5PxK/jtPk7/x0obnpczR8Tx14cjjlsyXK5CDlgPljWj4 kxfGQqGJpLjzNLGpO8dlYTfWrYx68muuJhY3Qm3hQTYGjFFWoek7oXHMFiZO5X3tpLn9SagHJ6nH 2KZEQ6POGSL2SGbb04gss2u8deQnyhQdTAewo0wL92982FKwaRpjItSybCl8EsXk+oJ+pugIi5Bi smZAo2HQJagrr5nOEb92NGjmP5wMd9p4xH5xOjn2ytcvg85PgsUlGwqRuHgDUDQNWYWQxi0PHhGR /JCmnz3NkIOGE/BxwI43LUbTGGvF55i4HKKHvu7GL6g5Q9PmBE2bC0xEMELElgSvu4d6lBWUN+33 PnwU0+SYq589zEDcadGaOuGFkBcqCm7CgpixQM7jBVpZQQXngehu3Zx8x+jCB4ozTW7rcSiGumGn nARxUOYMMZoWfLjpm4kh5PH9EXyRpbKkSUUj0gzjQczHO5ZWupL8z6sPXqBqW1OWxqqhgwNR7Plr K8mfGOubz+RUZcFOvIs+xSyaJQ4TrZ255dIZ6ckZ6RIrkZ8qhMrUR2ZHskmqxIKpuqdbx8otoqSO DZBSGgREP98Jl8iA6aUBYzFguhgwVu78a05SLGR8lKhZOhWb3Rk32XbCKlGjZD0uuNlLvA4TP31U 69WfF3itL9A6zOnEVXWfoSPIlgTLxGhbTCOMYKzL/R47CE6oTA11dy+VOyJbuVXDzhveAB2aip2r 6VR1quLB7WIj+CqNX43ah/fFrnI5mnGORnOOZmRNZj7zpiIYURF8Kgjb4g8Jlqo/WHgFaYwfkjCh 3pW3xKIoQLujhn6AHXcGfBTLg61vyTuShBgXPKaDF8wTOu1tFHLHe2I8XnQnySnqHPZS5BLMTc1o qeG4l7l8D1hiEA8l1GaoJYgseHt0WMoTiCgQEpXxGWjrbhodbwqa5LqU69jHyP/KUv4MvBKWQiEg Obhm10CUic1EBYs9C36oW7P9hJl+1/flUslRiyR9sZpj/7DYLT/L1lzNaJk7CNRsmpycSca3Mmsd CdVyoWpkpYV6z2WVt3f8J0c6jyrrTnYa2Mtq3RD2h66PzKkyELfpiaNiA/ZcroTNKEqd01qOX63O 10rvdAQt9YWysj4Z59w2n7Ar5lBFBlzMqHc49tLKuHXTQkXF/CooAnpb/V9BcQUJ2Hd0hrqZfVE3 1DbLWcc/8TP9tewxvHpyzRohkBiW5qHeMevfJ3zdWKriZS/J4axdj49iXG8cvP11JSWKzm6hl5aI NbJwW+zuDQbr3MFGmxc7WLTuDnsDAuSzHpxwhLoEQeqzDd/NXu4bolPwR2fBH3G3iZl36AfBhYwD KFLdKD0JXL84k6+1/TNPTM5iynkJ242kQYjdhGktgTilw4ZDFy+GIIotUhIE0NrrOIv87KuVeQ58 JJmwZ22pJcPGVaoygRHpR+Wh6Bx+H12kr7G1DpMrX+p0cb/rBaQeUR+aUo5rrvkyLbAQxereNbmp csvztBPqq7PFbsdvM/2IwncUL6f5k7X33S83cPPp35xt0D9g+eLr0muKu65bg1VMmkxsa+Yyar4M K89A7rvaTtbB0gk0pX+dsYvbAIdp0qNqaVpzaus1P14YMh0wXqLpxF0ijh6EyIlgR7eTYGQl6Cp9 II8Y2GRTlqxD/3aeFgsMr0khf3mzUQkZRS+MJEHvJ4H74gUVLrEYulgszW4wlI6Ufvy24YFHOVli xsicOj9N9r/zMn5gyHJFDymkhqN7jxT0kON3CJH5sv0PcIIbgEw5n0UOLI9V37h5WdsdjyZLrTc1 XZRFk8evIyFqHMSwr1xbly+QMwoUnUQ4/+Bx6Kb2dh7XFJU9NsHHLz+Y5BrxEvLx2XuOe/RMenSy 2QaHBTfJCHkYDdiONtJAS3cY40W4bW4RKxAWzVDs6MHyGkhdXBrZLcgPtSvQGPu9GUSCmdly6cSa OVYIaXQ32COwX0SFNHen3k4V09i3xVjII8Ye+o77Huexqzu/367+NwCosRtsCmVuZHN0cmVhbQ1l bmRvYmoNNCAwIG9iag08PCANL1R5cGUgL1BhZ2UgDS9QYXJlbnQgMTkgMCBSIA0vUmVzb3VyY2Vz IDUgMCBSIA0vQ29udGVudHMgNiAwIFIgDS9UaHVtYiAxMiAwIFIgDS9NZWRpYUJveCBbIDAgMCA2 MTIgNzkyIF0gDS9Dcm9wQm94IFsgMCAwIDYxMiA3OTIgXSANL1JvdGF0ZSAwIA0+PiANZW5kb2Jq DTUgMCBvYmoNPDwgDS9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIA0vRm9udCA8PCAvRjYgNyAwIFIg Pj4gDS9FeHRHU3RhdGUgPDwgL0dTMSA0OCAwIFIgPj4gDT4+IA1lbmRvYmoNNiAwIG9iag08PCAv TGVuZ3RoIDUyNSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiXxTS3OcMAy+8yt0 tDOFALMQ9tRpJ22nvfQQesr0QHZ5uAF7a5th+u8rWd6QHtLhIOv1SZ8kPrbJ7ecaCmiHpCghxw/F Mc/yqqzgLj9mRY6PdklyGJPbLw8FjC5J0Z/nNbSn5PrakkfxVRZldhCDTO+yWoCfevjx4QG8WnoL ysHcWXaN8ohxPci0yEWvzcqG6R3mkA1Deh3yjZ5lWpZo+CMLiglo6Oo8+W1PuNqA7d3FxFQtUxIu +LYJkeTP9hsSSIusQC73yd5++rp/Z5ZeHjDVT0qPMoDB0AWTmtl1zoDh2htEpAFQrgDZ/iIT41Uv k6kY+bvu4WLNxbhupq6W7hlJKGy4zCpB43lS44gCiSHx4qY+QKcDn0qciSlajXNg1sAbDnkD1O5k tv839AbVewMbE4JILOCy5RTErFjVnvfEVqO90it7HPYEPJ55NtsO4C1btQyL6DjVK0MsaBBsiCgu ThZWp5Azbfk6fGdYj3tB3Xoww06YKDU7u4bZhfAGkbsgR1bhKTTSiGdsC1VjAc44B7rJUsQYyxLt zGY3/V6pl2ugoyMrcWpcwuOIUIV4Qpg1rH6NmeFm+bVFUM0tvNQYGMaCC0svhWLAc/R3r4v+Qx9/ 1yt9ehL9k6wwykgCWC64X1I9i3BM4YWYJHQIcziFGiuwy2K1UrzHFkLxt87rU5v8FWAAGf4PUQpl bmRzdHJlYW0NZW5kb2JqDTcgMCBvYmoNPDwgDS9UeXBlIC9Gb250IA0vU3VidHlwZSAvVHlwZTEg DS9GaXJzdENoYXIgMzIgDS9MYXN0Q2hhciAxODEgDS9XaWR0aHMgWyAyNTAgMzMzIDQwOCA1MDAg NTAwIDgzMyA3NzggMTgwIDMzMyAzMzMgNTAwIDU2NCAyNTAgMzMzIDI1MCAyNzggNTAwIA01MDAg NTAwIDUwMCA1MDAgNTAwIDUwMCA1MDAgNTAwIDUwMCAyNzggMjc4IDU2NCA1NjQgNTY0IDQ0NCA5 MjEgDTcyMiA2NjcgNjY3IDcyMiA2MTEgNTU2IDcyMiA3MjIgMzMzIDM4OSA3MjIgNjExIDg4OSA3 MjIgNzIyIDU1NiANNzIyIDY2NyA1NTYgNjExIDcyMiA3MjIgOTQ0IDcyMiA3MjIgNjExIDMzMyAy NzggMzMzIDQ2OSA1MDAgMzMzIA00NDQgNTAwIDQ0NCA1MDAgNDQ0IDMzMyA1MDAgNTAwIDI3OCAy NzggNTAwIDI3OCA3NzggNTAwIDUwMCA1MDAgDTUwMCAzMzMgMzg5IDI3OCA1MDAgNTAwIDcyMiA1 MDAgNTAwIDQ0NCA0ODAgMjAwIDQ4MCA1NDEgMjUwIDI1MCANMjUwIDI1MCAyNTAgMjUwIDI1MCAy NTAgMjUwIDI1MCAyNTAgMjUwIDI1MCAyNTAgMjUwIDI1MCAyNTAgMjUwIA0yNTAgMjUwIDI1MCAy NTAgMjUwIDI1MCAyNTAgMjUwIDI1MCAyNTAgMjUwIDI1MCAyNTAgMjUwIDI1MCAyNTAgDTI1MCA1 MDAgNTAwIDI1MCAyNTAgMjUwIDI1MCAyNTAgNzYwIDI1MCAyNTAgMjUwIDI1MCAyNTAgMjUwIDI1 MCANNTY0IDI1MCAyNTAgMjUwIDUwMCBdIA0vRW5jb2RpbmcgL1dpbkFuc2lFbmNvZGluZyANL0Jh c2VGb250IC9UaW1lcy1Sb21hbiANL0ZvbnREZXNjcmlwdG9yIDM4IDAgUiANPj4gDWVuZG9iag04 IDAgb2JqDTw8IC9GaWx0ZXIgWyAvQVNDSUk4NURlY29kZSAvRmxhdGVEZWNvZGUgXSAvV2lkdGgg NzYgL0hlaWdodCA5OSAvQ29sb3JTcGFjZSAxNiAwIFIgDS9CaXRzUGVyQ29tcG9uZW50IDggL0xl bmd0aCA5IDAgUiA+PiANc3RyZWFtDQo4O1pdIj43TF1YJHE4a0wjLmttY2UuTHF0PG9LQDNTclxe R1BNcm1eLCIjPERgP08kLENeR1tkS1kkTDReJkFcXQpXYkBudGs8Q3I2Km5HNkdrLU9cX1o3aGsu VCVPI2U9a1RrLXIzJEskIjVla0ZcXjMuM1plcWVXLDIjRUsrM2s4IQo7QkZFUSctZjY3YyE6Qz1M bU5wcztBMnAvQCFVN0tbIXVwLDZbP3RqJmB0dCgjMC49bF1RPSxgXTxOXVQ+aXRDVwpSXF0lYlVQ UE42LzpGLVlAZVcpcyhuTVAycEdpcWVbV1xMakopKT8hYF1ROFdgWmQ6Jy09VUpKSTQnTk9fJiYv SApCbCNxL1EiTDRiXnBBZVo+Kyc3KCJfLzZBM0NGMkxGU210KD9DRkNKNVIpKD07JiNQVCE2LjVV Mlp+Pg1lbmRzdHJlYW0NZW5kb2JqDTkgMCBvYmoNMzIzIA1lbmRvYmoNMTAgMCBvYmoNPDwgL0Zp bHRlciBbIC9BU0NJSTg1RGVjb2RlIC9GbGF0ZURlY29kZSBdIC9XaWR0aCA3NiAvSGVpZ2h0IDk5 IC9Db2xvclNwYWNlIDE2IDAgUiANL0JpdHNQZXJDb21wb25lbnQgOCAvTGVuZ3RoIDExIDAgUiA+ PiANc3RyZWFtDQo4O1pdITslZ2AiI1hsQisiaEJaUkxJcmBsV1RhSkxwUVxFYmRVaCs9JjJkMUdP UDtMYUFNNm5ccEJwP3I5PUc3ZApSVyxdW1kkR1xmZ11RaCIjZnBWdUlyNk1sXnQ1MzxAQzBdM1VB ZDdVMzE3TjFGOyU3dFFPUGRhKyY1O1VRXktNaAomOUZoVjxSKlE0XEgob2AjKVNENWRdYGM7O0lp SV4kPV9ULHA8ZCYiXmInZzdRMzxobWFnYVRgVEdYImxSVW1MUApbSk0iRWxfREY5Nkc6MyprLSdj VW46LzNhYmFqcygpbS9aaUdZLG5fcFc9IkVmKipeQ1JPMFFaITxCQURJUHF+Pg1lbmRzdHJlYW0N ZW5kb2JqDTExIDAgb2JqDTI2MyANZW5kb2JqDTEyIDAgb2JqDTw8IC9GaWx0ZXIgWyAvQVNDSUk4 NURlY29kZSAvRmxhdGVEZWNvZGUgXSAvV2lkdGggNzYgL0hlaWdodCA5OSAvQ29sb3JTcGFjZSAx NiAwIFIgDS9CaXRzUGVyQ29tcG9uZW50IDggL0xlbmd0aCAxMyAwIFIgPj4gDXN0cmVhbQ0KODta XV01bWRUNyNSJXNCcyQ9QzVGS1IkSjhzbUgsTWVgSGs7YF5ZdGZdPz9zZXRrPWtsV0soIlEyWS5p b1coV08KVDdvbUUmY19uMyEhKUFjIVhvJ207dF0yfj4NZW5kc3RyZWFtDWVuZG9iag0xMyAwIG9i ag05MiANZW5kb2JqDTE0IDAgb2JqDTQ4MSANZW5kb2JqDTE1IDAgb2JqDTw8IC9GaWx0ZXIgWyAv QVNDSUk4NURlY29kZSAvTFpXRGVjb2RlIF0gL0xlbmd0aCAxNCAwIFIgPj4gDXN0cmVhbQ0KSixn XWcrZS9oXyFfZ0N0Tz0wZikkUCVjSWk4WmRmYzUmM2pfOCQ3Zy5ATGBZS1VKTkdCUFxwb1I9XztE bCdQKFQKKDdCb29eXlM6NzEoTU5dWlFYLytDYnUubEsicDc0cGUxVCVzLkRZJSZcMVRkSmhyNTQu TTlhdTY+NzluNmBROjQKUGJMU1pUTEVFKDhFQCcqMW1nXyplVG5OKjsqJ1YzK2dtLUVFZXRYJTtC byR1cjJzcypOYC4tIS5rR19xNkdERCcKZEtvTCE4S2EjRVYsQFYhXGo4WkZicDZFRTw5Y249TjZq PE04UT9bIzciZHEnMT4wbmY7KCY7UVU2YlVEJyljQFwKOS1kXERBPWNaMFE+Z0lNJCQ7Y2QyT0Am YTtYLE5uX2E8P1YtUFZFJT9TZl1pZEg2V1JacUhHcV1abTx1Q2kiXT8KU3RnKDxnVi1IOU5CPFNB XFQ9c04pSWwlKEJESWFrNy9IJm1WIWttRFVvNFg7ODtdVj5QKF1JMWFSYyhLMV51ZT4KZ0YvKCtH YUtvJHFuZUxXRHJRIzs1XFMoXCRxJzRRLDg1YC04O1MoPVoiV1NCT1YqRk0pNCw/Ql0sUjxnYlBO PSMKT21JSzxhOlxvOCtpb08tIVd+Pg1lbmRzdHJlYW0NZW5kb2JqDTE2IDAgb2JqDVsgDS9JbmRl eGVkIC9EZXZpY2VSR0IgMjU1IDE1IDAgUiANXQ1lbmRvYmoNMTcgMCBvYmoNPDwgDS9TIC9EIA0+ PiANZW5kb2JqDTE4IDAgb2JqDTw8IA0vTnVtcyBbIDAgMTcgMCBSIF0gDT4+IA1lbmRvYmoNMTkg MCBvYmoNPDwgDS9UeXBlIC9QYWdlcyANL0tpZHMgWyAzNCAwIFIgMSAwIFIgNCAwIFIgXSANL0Nv dW50IDMgDT4+IA1lbmRvYmoNMjAgMCBvYmoNPDwgDS9EdCAoRDoyMDAzMDMyMTExMzM0OCkNL0pU TSAoRGlzdGlsbGVyKQ0+PiANZW5kb2JqDTIxIDAgb2JqDS9UaGlzIA1lbmRvYmoNMjIgMCBvYmoN PDwgDS9DUCAoRGlzdGlsbGVyKQ0vRmkgMjEgMCBSIA0+PiANZW5kb2JqDTIzIDAgb2JqDTw8IA0v UENNIC9EZXZpY2VDTVkgDT4+IA1lbmRvYmoNMjQgMCBvYmoNPDwgDS9SIFsgMjQwMCAyNDAwIF0g DT4+IA1lbmRvYmoNMjUgMCBvYmoNPDwgDS9DbyAyMyAwIFIgDS9KVEYgMCANL01CIFsgMCAwIDYx MiA3OTIgXSANL1IgMjQgMCBSIA0vVyBbIDAgMiBdIA0+PiANZW5kb2JqDTI2IDAgb2JqDTw8IA0v RmkgWyAyMiAwIFIgXSANL1AgWyAyNSAwIFIgXSANPj4gDWVuZG9iag0yNyAwIG9iag08PCANL0N0 IChQbGFpbikNL0RtIFsgNjEyIDc5MiA2MTIgNzkyIF0gDT4+IA1lbmRvYmoNMjggMCBvYmoNPDwg DS9NZSAyNyAwIFIgDT4+IA1lbmRvYmoNMjkgMCBvYmoNPDwgDS9EIFsgMjYgMCBSIF0gDS9NUyAy OCAwIFIgDS9UeXBlIC9Kb2JUaWNrZXRDb250ZW50cyANPj4gDWVuZG9iag0zMCAwIG9iag08PCAN L0EgWyAyMCAwIFIgXSANL0NuIFsgMjkgMCBSIF0gDS9WIDEuMTAwMDEgDT4+IA1lbmRvYmoNMzEg MCBvYmoNPDwgDS9DcmVhdGlvbkRhdGUgKEQ6MjAwMzAzMjExMTMzNDgpDS9Qcm9kdWNlciAoQWNy b2JhdCBEaXN0aWxsZXIgNC4wNSBmb3IgV2luZG93cykNL0NyZWF0b3IgKFdpbmRvd3MgTlQgNC4w KQ0vVGl0bGUgKE1pY3Jvc29mdCBXb3JkIC0gTm9uSW52aXRlTm90ZXMuZG9jKQ0vTW9kRGF0ZSAo RDoyMDAzMDMyMTExMzM0OC0wOCcwMCcpDT4+IA1lbmRvYmoNeHJlZg0wIDMyIA0wMDAwMDAwMDAw IDY1NTM1IGYNCjAwMDAwMzgwNjkgMDAwMDAgbg0KMDAwMDAzODIzNSAwMDAwMCBuDQowMDAwMDM4 MzU4IDAwMDAwIG4NCjAwMDAwNDA1MzMgMDAwMDAgbg0KMDAwMDA0MDY5OSAwMDAwMCBuDQowMDAw MDQwODAwIDAwMDAwIG4NCjAwMDAwNDEzOTggMDAwMDAgbg0KMDAwMDA0MjE3OSAwMDAwMCBuDQow MDAwMDQyNjU4IDAwMDAwIG4NCjAwMDAwNDI2NzggMDAwMDAgbg0KMDAwMDA0MzA5OSAwMDAwMCBu DQowMDAwMDQzMTIwIDAwMDAwIG4NCjAwMDAwNDMzNzAgMDAwMDAgbg0KMDAwMDA0MzM5MCAwMDAw MCBuDQowMDAwMDQzNDExIDAwMDAwIG4NCjAwMDAwNDM5ODcgMDAwMDAgbg0KMDAwMDA0NDA0MCAw MDAwMCBuDQowMDAwMDQ0MDcxIDAwMDAwIG4NCjAwMDAwNDQxMTUgMDAwMDAgbg0KMDAwMDA0NDE5 MyAwMDAwMCBuDQowMDAwMDQ0MjU3IDAwMDAwIG4NCjAwMDAwNDQyODAgMDAwMDAgbg0KMDAwMDA0 NDMzMiAwMDAwMCBuDQowMDAwMDQ0MzczIDAwMDAwIG4NCjAwMDAwNDQ0MTUgMDAwMDAgbg0KMDAw MDA0NDUwMyAwMDAwMCBuDQowMDAwMDQ0NTU4IDAwMDAwIG4NCjAwMDAwNDQ2MTkgMDAwMDAgbg0K MDAwMDA0NDY1NSAwMDAwMCBuDQowMDAwMDQ0NzMyIDAwMDAwIG4NCjAwMDAwNDQ3OTkgMDAwMDAg bg0KdHJhaWxlcg08PA0vU2l6ZSAzMg0vSURbPGZhMjFjNzdkNDE2MjY3OTUzMGJlYWM2ZDQxZTI1 ZDYzPjxmYTIxYzc3ZDQxNjI2Nzk1MzBiZWFjNmQ0MWUyNWQ2Mz5dDT4+DXN0YXJ0eHJlZg0xNzMN JSVFT0YN --=-Kw37/HfBI5hw03WNxTHW-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Fri Mar 28 17:54:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22886 for ; Fri, 28 Mar 2003 17:54:51 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2SNGoP16438 for sip-archive@odin.ietf.org; Fri, 28 Mar 2003 18:16:50 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2SNGVO16375; Fri, 28 Mar 2003 18:16:31 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2RCc3O12562 for ; Thu, 27 Mar 2003 07:38:03 -0500 Received: from gorilla.mchh.siemens.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24727 for ; Thu, 27 Mar 2003 07:16:16 -0500 (EST) Received: from moody.mchh.siemens.de ([139.21.205.85]) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id NAA17536 for ; Thu, 27 Mar 2003 13:18:35 +0100 (MET) Received: from mchh247e.demchh201e.icn.siemens.de (mchh247e.mchh.siemens.de [139.21.200.57]) by moody.mchh.siemens.de (8.9.3/8.9.1) with ESMTP id NAA25719 for ; Thu, 27 Mar 2003 13:18:36 +0100 (MET) Received: by mchh247e.mchh.siemens.de with Internet Mail Service (5.5.2656.59) id ; Thu, 27 Mar 2003 13:18:19 +0100 Message-ID: <3D72C18DF140D311A54F0008C7DBAC8D02A5F53E@mchh252e.mchh.siemens.de> From: Deuringer Wolfgang To: "'sip@ietf.org'" Date: Thu, 27 Mar 2003 13:18:15 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="ISO-8859-1" Subject: [Sip] RFC 3325 - Private Extensions to SIP for Asserted Identity within Trusted Networks Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Dear all, the RFC3325 states in Chapter 11.2 Authentication requirements that "Users must be authenticated using SIP Digest Authentication". This contradicts the statement in the SIP discussion list that the P-Asserted-Identity should be available in response messages, too. However I see no way to authenticate response messages with SIP mechanisms. Additionally the RFC shows the usage of these headers only for Requests. If there is a common understanding that the P-Asserted-Identity header is required for responses, will there be an update of the RFC? * What happens in a case where a proxy receives a response from a node he does not trust? He cannot authenticate the originator of the response. This means that he can only set up the P-Asserted-Identity for responsens of users which are stored within the database which is accessible by the proxy. * Does this mean that response messages from users not available in the database would be skipped by the proxy. * Which responses should contain this P-Asserted-Identity Header? Only final responses or even provisional ones? Best regards, Wolfgang Deuringer ____________________________________________________ Wolfgang Deuringer ICN CP D NA D12 Mch H/Sc8 Tel. +49 89 722 28236 Fax + 49 89 722 48697 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Sun Mar 30 08:58:15 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26914 for ; Sun, 30 Mar 2003 08:58:15 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2UEL2H06008 for sip-archive@odin.ietf.org; Sun, 30 Mar 2003 09:21:02 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2UEKKO05998; Sun, 30 Mar 2003 09:20:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2UE5xO04976 for ; Sun, 30 Mar 2003 09:05:59 -0500 Received: from em.njupt.edu.cn (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA26821 for ; Sun, 30 Mar 2003 08:42:40 -0500 (EST) Received: (qmail 5213 invoked by uid 1008); 30 Mar 2003 14:28:10 -0000 Message-ID: <20030330142810.5212.qmail@em.njupt.edu.cn> References: In-Reply-To: From: Y01317@njupt.edu.cn To: Vijay Gaur Cc: sip@ietf.org Date: Sun, 30 Mar 2003 14:28:10 GMT Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="gb2312" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Re: SIP Client Transaction Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Vijay Gaur writes: > Hi, > RFC 3261 section "17.1.1.1 Overview of INVITE Transaction" specifies the > state machine for Client INVITE transaction. In the diagram if client > transaction state comes to proceeding after receiving 1xx message, no timers > are started. It is not specified that if no message is received further in > this state, how this transaction will be terminated. There is no timer > specified to clear this transaction. Do we need to start timer B again in > this state and clear the transaction after timer B expiry? > Your feedback is appreciated. > Thanks, > Vijay > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip Timer C can do this thing. If Timer C fires, the transaction will be killed. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Mon Mar 31 01:33:58 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15407 for ; Mon, 31 Mar 2003 01:33:58 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2V6v4q30961 for sip-archive@odin.ietf.org; Mon, 31 Mar 2003 01:57:04 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2V6uNO30906; Mon, 31 Mar 2003 01:56:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2V6oUO30708 for ; Mon, 31 Mar 2003 01:50:30 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15242 for ; Mon, 31 Mar 2003 01:26:53 -0500 (EST) From: Jussi.Turunen@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.5) with ESMTP id h2V6XC508705 for ; Mon, 31 Mar 2003 09:33:13 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 31 Mar 2003 09:29:20 +0300 Received: from esebe009.NOE.Nokia.com ([172.21.138.41]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 31 Mar 2003 09:29:16 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] Event header in responses Date: Mon, 31 Mar 2003 09:29:15 +0300 Message-ID: Thread-Topic: [Sip] Event header in responses Thread-Index: AcL3TtnwP0KoZuNnQUyHwkmyo3RqrQ== To: Cc: X-OriginalArrivalTime: 31 Mar 2003 06:29:16.0589 (UTC) FILETIME=[DA8BA5D0:01C2F74E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2V6oUO30709 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Bug 677 (http://www.sipwg.org/sipwg/show_bug.cgi?id=677) says that there is confilicting text in RFC 3265 about Event header in responses. The wording of the bug is not 100% clear, but I assume that responses should not contain an Event header. The reason for my question is that SIP Service Examples-04 and shows no Event in responses, presence-10 call flow example shows it, event-list-01 draft shows it sometimes. What is the correct interpretation? Jussi _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Mon Mar 31 05:02:43 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00642 for ; Mon, 31 Mar 2003 05:02:43 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2VAPtn23146 for sip-archive@odin.ietf.org; Mon, 31 Mar 2003 05:25:55 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2VAPQO23133; Mon, 31 Mar 2003 05:25:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2VALRO23026 for ; Mon, 31 Mar 2003 05:21:27 -0500 Received: from mail.astri.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00582 for ; Mon, 31 Mar 2003 04:57:41 -0500 (EST) Received: from patrickXP (Firewall [203.198.202.1]) by mail.astri.org (8.11.6/8.11.2) with ESMTP id h2VA2lY19800 for ; Mon, 31 Mar 2003 18:02:49 +0800 From: "Patrick Lam" To: Date: Mon, 31 Mar 2003 18:02:36 +0800 Message-ID: <008a01c2f76c$a8ac0690$2306050a@patrickXP> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_008B_01C2F7AF.B6CF4690" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal X-MS-TNEF-Correlator: 00000000A495D97211F6D54497CF24BD1531C79FE47A2800 Subject: [Sip] Difference between dialog and session in SIP? Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_008B_01C2F7AF.B6CF4690 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Dear all: I am a little confused about the concept of a dialog. What exactly is the difference between a dialog and a session? Does dialog mean a "call has already been setup" in the signaling sense, while a session mean the "media has already been setup" in the media sense? Also, what does "part of a dialog" mean? Are "INVITE", "ACK" and the responses considered "part of a dialog"? What does "outside the dialog" mean then? Is a request is outside the dialog, does it still affect or change anything "inside the dialog" then? Thanks very much in advance, Regards, Patrick ------=_NextPart_000_008B_01C2F7AF.B6CF4690 Content-Type: application/ms-tnef; name="winmail.dat" Content-Disposition: attachment; filename="winmail.dat" Content-Transfer-Encoding: base64 eJ8+IiUKAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEGgAMADgAAANMHAwAfABIAAgAAAAEAEQEB A5AGABwOAAAnAAAACwACAAEAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAADADYAAAAAAB4AcAAB AAAALgAAAERpZmZlcmVuY2UgYmV0d2VlbiBkaWFsb2cgYW5kIHNlc3Npb24gaW4gU0lQPwAAAAIB cQABAAAAFgAAAAHC92ynw0vnD9rUEktulyNaDFU7tQMAAAIBHQwBAAAAGAAAAFNNVFA6UEFUUklD S0xAQVNUUkkuT1JHAAsAAQ4AAAAAQAAGDgCcIZJs98IBAgEKDgEAAAAYAAAAAAAAAKSV2XIR9tVE l88kvRUxx5/CgAAAAwAUDgAAAAALAB8OAQAAAAIBCRABAAAA0wkAAM8JAAAXHQAATFpGddCCDKeD AAoAcmNwZzk1AUAMdWMAUAEEc3RzaMEFcGJjaDE0DvQJAJsPcA7laA3gEEZiaQFDgQtgbmcxMDMz EabkZmUSIDI4AfcCpANjRwIAD3AKwHNldALRcChycTIAACoKoW5vrRTgIBMQFjE2EjAwDjDONBax AdAWoDR9B20Cg+8AUAPUFI8Vm2IWcRbgFkI/G4QXYAcTGHQPoBQtMTMeNhnvFjMWoB+rfVBNoQuA Z0xpVRWCZgdACQVAIVAL8E9jdUH8ZX0Cgx4SHS8ePx9PIFImQCCWGHQyNxQeMjOKOCPkIAdtIENF JtWfKHEnfRbQKI8plXlyGHS7FqAivzYYwSvvA4JHCdFuay1lGMEuDjIvHymUVO8IcC1lMnEi3Tcn QTKvA4KQKEhlYglwdyktZf8SUDS/KH821gcQAaAN4De22Rz/MTgj1TnfQiFhDeB1LWU1O+82ODE9 PzcDVtEIkHRuYQeBZTe2J0H/GPwoWAcTKecoYkNtK6dE5b8tRhbgGN4u6ETkMIk0GM/3MlhE5DP3 NDJxSL01t0TkvTdMNDgxTj5EbDrsNDvR70i9PPdE5D6KND9RSL5AhuNPtUIeMjY5FB9AlSCWdCBX B5B0BJEhHyIlNP44Wi9bNiZHXDYCgAKRCOYKOwlvMGHPZTI1Nf9i+mQRY89k2WLkZQJjb2c//2b9 Zn9kr2L/EvATIGzKKmL/ba9uuGLkKmJtP3EPcM1wT/tuf3JEOTJwdZR28W8TdvBTAoIPAHlsB5Bo CeB09QAAcQMhbBGBBRABQBXgYQPwZGN0bAqxAGBzjwqwelAZcHqSbnVtXOEQYXV0bwBgZGp14w8A BRBnaHR5kQoBeWClCgFpAZBwMAOyMg+g8xHnEqhcawSRILEycBASfwKyEMIAYAEyD2GAwQ+RY+cJ wHoQfiNucH55glITIOEDMHNuZXgZwAewBbDnAMACcxWgY3MSIAMwfBByZH1waXYWEA7wGaBtzmkQ wIVACfAgRAEQe8A1XRFQCsBhCcB9kGgg7kYCIYR0DxAxAFAPEANgTncLMHxgAYBzV3oQdLxoQhJQ fGAKsIVAbBIg+zlgieRyilgQAInGAYCLx8pii8dyicJjYgqwI6CPjbIj8I4TBPBlbGx6Af+JkIkx AUAPEIWQACBdAYhB/zdwiuCQZglQkIQMsZCTeoD5kIRkZ5FmkuCSZoAwkIT+dgMweSp6D3sffC99 PJiR/xHzfgUS434RgB+BL4I0mif/nVSDhYhwhbyEFEDwAaB4kH2EdzWFGobQCNBZ8IOBYn+WMAmA AiCE8nhhGZCVoDgCNWWBNDYgSHlw/wSQfSEww4SzpCChbicgon//o4qHsI8gefAJgKRPNaCFGv8L 445wmJGbEwBQm4UOgZwm76athekO8KRhcwIgRREO8NkFoG1wFfKjTkUAwAMQvlN4cjWgYPMVoGHg dgJR+CB7VaSweeFg5LIRo5HPsmKzgyhgEjA4NwBQo4mbs4OhMDkxMBbQM30KoXWkYXeIcDkWcLZ0 D4A2fjgoYAMwAWReMALRQkBi/moAYAnwhUAQIAIBhDAPIO2XoGWbcAWwerlSkuAAwOxyZwuBkuBo lkGPADzg+QFBZ3a7eboxmBALgDWgzjAOgbwQvPU5OA+gu0LdujB3u+S+wTJwaq+CYeD9GSFsFeAS AIHSuVF4cKRgpTJwdgiQd2sLgGQ/UD/BYgTwB0AS8Q7hC1B5dP+zAAuAuhC4scL3mDAAwJdg/5ZA DGAZoF0QptDAQABgwED/AlHBsXlQwwDCUZXAAmCI4T/C8QJRACCTkcBAN3Brcu+G0LoQFeDHsXeJ 8Akyg6B/fZCXcIHCC4CPAsVhqKFmdQiQbIZRZMThlYCJ8HD+dcmgmECWMAcwx6ejggNgfm8joLX1 AzEZshmglcBk73lCg7EBQLkhbnjAYeDN09/OUoHCI8DNxK7BYwaQeIA/DvC4s7KQFZIAgAWQbHb/ ikDRwQ5ghDDRwgGQACDSUvvBsQnwdAHB0cEZcBIA0YHnluAM0AGQIC6x1NHWMnD/0nJdEJYQ0u/T /9UPi7GW4P8Fgda/18/Y39IwD6CW4MZg99aP21/cZSnVTD9Q2i/fH/3cRWI3MAKR4E/SA7ch3f// 4s/j3+Tv0jAnQOYy0r/nn//or+C9OWDmP+vP7N/t79Ih/15Q6s/wb/F/8oUK+ZS8ee//lo+Xn30Z CqIZgaOofd9+7/+a9JvSm4+Bn4KtGJU84KsjvwuAiLD9Sqv/muafAEQFn+0GqWUKwcoBOhiGBDy0 ZeggDQr84iAJrwTLC4XrB28GqUkJUG0OPwaa3LCX+IDHAHiQIK+AbmYQX68GqcTRziA7EG/68CCJ kH8S7wh6FX8GqRKSjwDIoCD+bxLfGEvcsIVQxlDJQAv/1wTPGf8G5S4Y8FcjUF0g54PAvFD5YHkg SNAVQaqwnYVQZpqQYeDJoSBizaD/qMCGYRuGCVC5MBIBJMBI4Lpph8A/GPAd7waqbzoR/yJlOgAp wSPfEWscDx0cACXnJyoAswchXCe2ACiPHR//Ju8G5cJR+FBJMDogxlBh4P/7MCCALG8tfy6PBuUh wIZhnzEfMi8zPwblSWF1cDUP9ymfKq8ruDQ4/zYfNy8Ylv/4ASDSy7ACcMZQW9EjIdHh+CwgdwCw EnEjFyZEINL/PN86DzsfK79D/z5PP18mQf8boTBDSV8RajClNLM4r0g//0VvO99Or0ifTA9AHEsU QZOOPwuFDd9U/yBBbK8A/0HiH/GnECWxUn9Pr1C/Rs/3W19T71jfIPmBGXIbf19f/1yPXZ9ST2Rf YM8YaSZSaT//Gskjr1kdzyFtTxhpZ19kjz9ln14vcV9oz2/PD/BOVvhJVEV033IPcx9mr3k/+3ZP d18gQeB8v3nvev90L8+A334vfz9Z4ENLhF+Bj/+Cn3wPiI+Fz4bfG2Ei4SDS/7/xr7DR4TBwEqGj kc8RziD/jA+JP4pPg6+R741/jo9ib/+Vb5Kfk6+LX5pvlt+X72zw/1dfn/8a9h/TWq+er5vflG// pO+fD6LPGxQVEZECIMWZz/+pj6a/nP+tn6nvqv9qqCDCPyOQsz8ayg/wMHGQIXF178AApGAgoaxf Z1owpIP8kP0jIHRCIPhQsV+yb7XvEaZ/ITH5UBmACUAA0P5hQkFu/8YgALDcEbqvro+vn6gPwE// vB+9L0BxrI/D78Efwi+wz3/I/8Vftm+1U6Gfzm8a9lS12/FrS5B2/6AggG3WYLZoQHL7MHYi0CGQ LNBfo9FvGvZSZWf3kXPUr5vVvxrnUB/w+5Bja8xfN81qCkBLcHINHwvRfQAB3mAAAwDeP59OAAAD AAlZAwAAAAMAQGUAAAAACwATgAggBgAAAAAAwAAAAAAAAEYAAAAAA4UAAAAAAAADABWACCAGAAAA AADAAAAAAAAARgAAAAAQhQAAAAAAAAMAG4AIIAYAAAAAAMAAAAAAAABGAAAAAFKFAAAblwEAAwAi gAggBgAAAAAAwAAAAAAAAEYAAAAAAYUAAAAAAABAACOACCAGAAAAAADAAAAAAAAARgAAAABghQAA AMwL8bz//x8LAEKACCAGAAAAAADAAAAAAAAARgAAAACChQAAAQAAAB4ASYAIIAYAAAAAAMAAAAAA AABGAAAAAFSFAAABAAAABQAAADEwLjAAAAAACwB1gAggBgAAAAAAwAAAAAAAAEYAAAAABoUAAAAA AAALAHaACCAGAAAAAADAAAAAAAAARgAAAAAOhQAAAAAAAAMAd4AIIAYAAAAAAMAAAAAAAABGAAAA ABiFAAAAAAAAAgH4DwEAAAAQAAAApJXZchH21USXzyS9FTHHnwIB+g8BAAAAEAAAAKSV2XIR9tVE l88kvRUxx58CAfsPAQAAAJYAAAAAAAAAOKG7EAXlEBqhuwgAKypWwgAAbXNwc3QuZGxsAAAAAABO SVRB+b+4AQCqADfZbgAAAEM6XERvY3VtZW50cyBhbmQgU2V0dGluZ3NccGF0cmlja2xcTG9jYWwg U2V0dGluZ3NcQXBwbGljYXRpb24gRGF0YVxNaWNyb3NvZnRcT3V0bG9va1xPdXRsb29rLnBzdAAA AAMA/g8FAAAAAwANNP03AgACARQ0AQAAABAAAABOSVRB+b+4AQCqADfZbgAAAgF/AAEAAAAxAAAA MDAwMDAwMDBBNDk1RDk3MjExRjZENTQ0OTdDRjI0QkQxNTMxQzc5RkU0N0EyODAwAAAAAAMABhCh 1rk9AwAHENkBAAADABAQAAAAAAMAERAAAAAAHgAIEAEAAABlAAAAREVBUkFMTDpJQU1BTElUVExF Q09ORlVTRURBQk9VVFRIRUNPTkNFUFRPRkFESUFMT0dXSEFURVhBQ1RMWUlTVEhFRElGRkVSRU5D RUJFVFdFRU5BRElBTE9HQU5EQVNFU1NJTwAAAAAZFw== ------=_NextPart_000_008B_01C2F7AF.B6CF4690-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Mon Mar 31 08:10:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05525 for ; Mon, 31 Mar 2003 08:10:59 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2VDYDY02238 for sip-archive@odin.ietf.org; Mon, 31 Mar 2003 08:34:13 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2VDR9O01865; Mon, 31 Mar 2003 08:27:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2VDMaO01700 for ; Mon, 31 Mar 2003 08:22:36 -0500 Received: from znsgs01r.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05274 for ; Mon, 31 Mar 2003 07:58:50 -0500 (EST) Received: from znsgy0k8.europe.nortel.com (europem01.nt.com [47.165.24.67]) by znsgs01r.nortelnetworks.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2VD1A612684; Mon, 31 Mar 2003 14:01:11 +0100 (BST) Received: from zwcwc012.europe.nortel.com ([47.160.46.124]) by znsgy0k8.europe.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HG1L072L; Mon, 31 Mar 2003 14:01:09 +0100 Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 31 Mar 2003 14:00:12 +0100 Message-ID: X-Sybari-Space: 00000000 00000000 00000000 From: "Mark Watson" To: "'Deuringer Wolfgang'" , "'sip@ietf.org'" Subject: RE: [Sip] RFC 3325 - Private Extensions to SIP for Asserted Ident ity within Trusted Networks Date: Mon, 31 Mar 2003 14:00:08 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2F785.7513C098" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This 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_01C2F785.7513C098 Content-Type: text/plain; charset="iso-8859-1" Wolfgang, Section 11 of the RFC is just an example. The point of the mechanism in this RFC is that P-Asserted-Identity can only be used within a 'trusted domain', but that to make this concept meaningful, you must provide concrete details of the requirements that are met by all elements of the trusted domain. This is called Spec(T), and section 11 gives an example. Nevertheless, this statement simply says that users must be authenticated using SIP Digest Authentication. I cannot see what relevance this has to whether P-Asserted-Identity may be used in responses. The handling of responses from a node outside the Trust Domain is a sub-case of the handling of messages described in section 5: "A proxy in a Trust Domain can receive a message from a node that it trusts, or a node that it does not trust. When a proxy receives a message from a node it does not trust and it wishes to add a P- Asserted-Identity header field, the proxy MUST authenticate the originator of the message, and use the identity which results from this authentication to insert a P-Asserted-Identity header field into the message." This does not specify how or when the originator of the message is authenticated. If you were using the Spec(T) specified in Section 11, then Digest is the only method of authentication specified, so clearly this cannot be carried out at the point at which the response is received. The proxy would need some means to ascertain that the message (response) came from the same user it had previously authenticated with Digest (such means being a form of authentication in themselves). This 'some means' ought to be specified in Spec(T), but as Section 11 is just an example, I don't think it is necessary to update the RFC. Regards, Mar > -----Original Message----- > From: Deuringer Wolfgang [mailto:wolfgang.deuringer@siemens.com] > Sent: 27 March 2003 12:18 > To: 'sip@ietf.org' > Subject: [Sip] RFC 3325 - Private Extensions to SIP for Asserted > Identity within Trusted Networks > > > > Dear all, > > the RFC3325 states in Chapter 11.2 Authentication > requirements that "Users must be > authenticated using SIP Digest Authentication". This > contradicts the statement in the SIP discussion > list that the P-Asserted-Identity should be available in > response messages, too. However I see no > way to authenticate response messages with SIP mechanisms. > Additionally the RFC shows the usage > of these headers only for Requests. > > If there is a common understanding that the > P-Asserted-Identity header is required for responses, > will there be an update of the RFC? > * What happens in a case where a proxy receives a > response from a node he does not trust? He cannot > authenticate the originator of the response. This means that > he can only set up the P-Asserted-Identity > for responsens of users which are stored within the database > which is accessible by the proxy. > * Does this mean that response messages from users not > available in the database would be skipped by the > proxy. > * Which responses should contain this P-Asserted-Identity > Header? Only final responses or even provisional ones? > > > Best regards, > > Wolfgang Deuringer > > > ____________________________________________________ > Wolfgang Deuringer > ICN CP D NA D12 > Mch H/Sc8 > Tel. +49 89 722 28236 > Fax + 49 89 722 48697 > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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_01C2F785.7513C098 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Sip] RFC 3325 - Private Extensions to SIP for Asserted = Identity within Trusted Networks

Wolfgang,

Section 11 of the RFC is just an example.

The point of the mechanism in this RFC is that = P-Asserted-Identity can only be used within a 'trusted domain', but = that to make this concept meaningful, you must provide concrete details = of the requirements that are met by all elements of the trusted domain. = This is called Spec(T), and section 11 gives an example.

Nevertheless, this statement simply says that users = must be authenticated using SIP Digest Authentication. I cannot see = what relevance this has to whether P-Asserted-Identity may be used in = responses.

The handling of responses from a node outside the = Trust Domain is a sub-case of the handling of messages described in = section 5:

  "A proxy in a Trust Domain can receive a = message from a node that it
   trusts, or a node that it does not = trust.  When a proxy receives a
   message from a node it does not trust = and it wishes to add a P-
   Asserted-Identity header field, the = proxy MUST authenticate the
   originator of the message, and use the = identity which results from
   this authentication to insert a = P-Asserted-Identity header field into
   the message."

This does not specify how or when the originator of = the message is authenticated. If you were using the Spec(T) specified = in Section 11, then Digest is the only method of authentication = specified, so clearly this cannot be carried out at the point at which = the response is received. The proxy would need some means to ascertain = that the message (response) came from the same user it had previously = authenticated with Digest (such means being a form of authentication in = themselves).

This 'some means' ought to be specified in Spec(T), = but as Section 11 is just an example, I don't think it is necessary to = update the RFC.

Regards,

Mar

> -----Original Message-----
> From: Deuringer Wolfgang [mailto:wolfgang.deuringer= @siemens.com]
> Sent: 27 March 2003 12:18
> To: 'sip@ietf.org'
> Subject: [Sip] RFC 3325 - Private Extensions to = SIP for Asserted
> Identity within Trusted Networks
>
>
>
> Dear all,
>
> the RFC3325 states in Chapter 11.2 = Authentication
> requirements that "Users must be
> authenticated using SIP Digest = Authentication". This
> contradicts the statement in the SIP = discussion
> list that the P-Asserted-Identity should be = available in
> response messages, too. However I see no
> way to authenticate response messages with SIP = mechanisms.
> Additionally the RFC shows the usage
> of these headers only for Requests.
>
> If there is a common understanding that the =
> P-Asserted-Identity header is required for = responses,
> will there be an update of the RFC?
> *     What happens in a = case where a proxy receives a
> response from a node he does not trust? He = cannot
> authenticate the originator of the response. = This means that
> he can only set up the = P-Asserted-Identity
> for responsens of users which are stored within = the database
> which is accessible by the proxy.
> *     Does this mean that = response messages from users not
> available in the database would be skipped by = the
> proxy.
> *     Which responses = should contain this P-Asserted-Identity
> Header? Only final responses or even = provisional ones?
> 
>
> Best regards,
>
>       Wolfgang = Deuringer
>
>
> = ____________________________________________________
> Wolfgang Deuringer
> ICN CP D NA D12
> Mch H/Sc8
> Tel.  +49 89 722 28236
> Fax  + 49 89 722 48697
>
>
>
> = _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core = SIP 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_01C2F785.7513C098-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Mon Mar 31 08:15:09 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05598 for ; Mon, 31 Mar 2003 08:15:09 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2VDcO703156 for sip-archive@odin.ietf.org; Mon, 31 Mar 2003 08:38:24 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2VDUCO01987; Mon, 31 Mar 2003 08:30:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2VDOjO01782 for ; Mon, 31 Mar 2003 08:24:45 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05311 for ; Mon, 31 Mar 2003 08:00:59 -0500 (EST) From: hisham.khartabil@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.5) with ESMTP id h2VD7J502400 for ; Mon, 31 Mar 2003 16:07:19 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 31 Mar 2003 16:03:23 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 31 Mar 2003 16:03:23 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 31 Mar 2003 16:03:23 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Mon, 31 Mar 2003 16:03:23 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7FE7467@esebe019.ntc.nokia.com> Thread-Topic: A couple of nits in RFC3261 Thread-Index: AcL3hekzJIgH6tIiTaq+5Eql1ixeKg== To: X-OriginalArrivalTime: 31 Mar 2003 13:03:23.0761 (UTC) FILETIME=[E95BBE10:01C2F785] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2VDOjO01783 Subject: [Sip] A couple of nits in RFC3261 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit - In section 13.2.2.4 Second last paragraph says: The UAC core considers the INVITE transaction completed 64*T1 seconds after the reception of the first 2xx response. At this point all the early dialogs that have not transitioned to established dialogs are terminated. Once the INVITE transaction is considered completed by the UAC core, no more new 2xx responses are expected to arrive The problem is with the word "established" above. It should say "confirmed", since early dialogs are in fact established. A related problem in that the words "created" and "established" are interchangeable in the rfc, and cause confusion. We should use just one of them? - In section 15, Second paragraph: However, the callee's UA MUST NOT send a BYE on a confirmed dialog until it has received an ACK for its 2xx response or until the server transaction times out For confirmed dialogs, the server transaction is already terminated and therefore cannot time out. It should say "... or until UAS core has the 2xx response for 64*T1 seconds without receiving an ACK. Regards, Hisham _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Mon Mar 31 09:18:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06972 for ; Mon, 31 Mar 2003 09:18:57 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2VEgEd07195 for sip-archive@odin.ietf.org; Mon, 31 Mar 2003 09:42:14 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2VEYpO06140; Mon, 31 Mar 2003 09:34:51 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2VBMgO26547 for ; Mon, 31 Mar 2003 06:22:42 -0500 Received: from mail.tssg.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01451 for ; Mon, 31 Mar 2003 05:58:59 -0500 (EST) Received: from boolard (unknown [10.37.1.56]) by mail.tssg.org (Postfix) with SMTP id 92818180EF for ; Mon, 31 Mar 2003 11:01:29 +0000 (GMT) From: "Shane McCormack" To: Date: Mon, 31 Mar 2003 12:05:27 +0100 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0216_01C2F77D.D1B751A0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <008a01c2f76c$a8ac0690$2306050a@patrickXP> Importance: Normal X-MS-TNEF-Correlator: Subject: [Sip] SIP servlet location implementation Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0216_01C2F77D.D1B751A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, I wish to implement a sip servlet that subscribes to different users that can theoretically receive geographical location NOTIFY reports. Would the correct scenario be for a servlet to send these SUBSCRIBE messages to each user or use a non-SIP entity such as a GPS Location Server? Regards Shane McCormack Research Assistant, TSSG, Confederation House, Waterford Business Park, Cork Road, Waterford, Co. Waterford. Phone: +353 51 302927 Fax: +353 51 302901 Mobile: +353 87 9955505 MSN: mccormackshane@hotmail.com ------=_NextPart_000_0216_01C2F77D.D1B751A0 Content-Type: application/ms-tnef; name="winmail.dat" Content-Disposition: attachment; filename="winmail.dat" Content-Transfer-Encoding: base64 eJ8+IhwLAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEGgAMADgAAANMHAwAfAAwABAAAAAEADQEB A5AGAIAHAAAkAAAACwACAAEAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAADAC4AAAAAAAMANgAA AAAAHgBwAAEAAAAuAAAARGlmZmVyZW5jZSBiZXR3ZWVuIGRpYWxvZyBhbmQgc2Vzc2lvbiBpbiBT SVA/AAAAAgFxAAEAAAAbAAAAAcL3bKfDS+cP2tQSS26XI1oMVTu1AwACFDJQAAIBHQwBAAAAGQAA AFNNVFA6U01DQ09STUFDS0BUU1NHLk9SRwAAAAALAAEOAAAAAEAABg4AkGw7dffCAQIBCg4BAAAA GAAAAAAAAACEbqFhtsN6SLVppa/fR3ZewoAAAAsAHw4BAAAAAgEJEAEAAAAtAwAAKQMAAIoEAABM WkZ1uy3kSoMACgByY3BnOTUBQwMBNAtgbmcxMDMzSQ62ZmUPMDI4AVU0njgB6AKkA+MCAGNoCsBg c2V0MCAHEwKAfRMKgAjIIDsJbzI1NUsCgAqBdgiQd2sLgGT6NAxgYwBQCwMM0AHBDMGIMTQ0F0Iy MTYXszY4ENAMwTMYEBdCNDOnFzMOMBejNTcYEzYQwWsW9BrDORczOBqQF0I5fxjRF1IY8BiDDzAQ 0BdDMbI1FzQyMhejHkA5HHRvGNAc9BeRF0M1HkAgBDj5HnQ2NRx0AcAc9B1hIgT1FyU5F5UwGAUc 4BiDF/LdF7MyGVQlUBnCYwBBC7UwIEhpLArjCoBJIMED8WggdG8gB3ALUEZlB4ACMCBhIACQcNso 0ASQdihQBUB0EmAFQGhzdWIE8mIHkSfxZO8GkA/wCXAokXUpISqBKbL2YwORKaBlBbASoA3gB0AI bHkgCXBjZWl2GGUgZyyACcBhcGh9LNIgCQAsICzAAiAHsE9QVElGWS0xcAkRc8guIFcIYGxkLFIs EG8FsC1BKdEtYG4KwC7gIP0qYCACEAXAKMEpNigAEpAPFjAsUhKQBgBVQlNDIFJJQkUgB4FzYbst wCqDZQDQJ9ArciAFsQsrcSixbgIgLVNJUHM1EAIwaXQtICnwNUFh0wQgKMBHUAXwTC6mBmEZLZBy PyckJyRSZWe/CxESIDk5CvQmIAvDNAYApRJgbi2gTWMIUHIAwd5rOSwSkArANUFBBBAEAGMBkAIw LFxsC4AtoFTYU1NHJwAIUG4P8ASBvS7ESAhgEpAnAT7zVynAdwSQMgEwYEIrcD8BBBFQnQrAaz+C QqAH8WFkQN8/P4IwAUFmMAA6WyaTUGgBAiBlOiArMzUzGiAgUCAl0B7QMjdcwn5IBCBGYXhHDCPQ cUDlTW9iAxBG9iLQICY5DiAVYDA1QOU8aEECQHA6Ly93TJAuES/gc2cuBbBnLz55ScZTTkcAJhMw QDRQY68FoTyyJ8A8IUBGwHQAwHUDEC4FoG1MAE/SJ/A6+06/T8c+O2MwQDZRLaADsl8eYDpbSBA5 ORNRAFWQAAAAHgBCEAEAAAArAAAAPDAwOGEwMWMyZjc2YyRhOGFjMDY5MCQyMzA2MDUwYUBwYXRy aWNrWFA+AAALAAGACCAGAAAAAADAAAAAAAAARgAAAAADhQAAAAAAAAMAA4AIIAYAAAAAAMAAAAAA AABGAAAAABCFAAAAAAAAAwAHgAggBgAAAAAAwAAAAAAAAEYAAAAAUoUAALZ0AQAeAAmACCAGAAAA AADAAAAAAAAARgAAAABUhQAAAQAAAAQAAAA5LjAACwANgAggBgAAAAAAwAAAAAAAAEYAAAAAgoUA AAEAAAALADqACCAGAAAAAADAAAAAAAAARgAAAAAOhQAAAAAAAAMAPIAIIAYAAAAAAMAAAAAAAABG AAAAABGFAAAAAAAAAwA9gAggBgAAAAAAwAAAAAAAAEYAAAAAGIUAAAAAAAALAFKACCAGAAAAAADA AAAAAAAARgAAAAAGhQAAAAAAAAMAU4AIIAYAAAAAAMAAAAAAAABGAAAAAAGFAAAAAAAAAgH4DwEA AAAQAAAAhG6hYbbDeki1aaWv30d2XgIB+g8BAAAAEAAAAIRuoWG2w3pItWmlr99Hdl4CAfsPAQAA AJwAAAAAAAAAOKG7EAXlEBqhuwgAKypWwgAAUFNUUFJYLkRMTAAAAAAAAAAATklUQfm/uAEAqgA3 2W4AAABDOlxEb2N1bWVudHMgYW5kIFNldHRpbmdzXHNtY2Nvcm1hY2tcTG9jYWwgU2V0dGluZ3Nc QXBwbGljYXRpb24gRGF0YVxNaWNyb3NvZnRcT3V0bG9va1xvdXRsb29rLnBzdAADAP4PBQAAAAMA DTT9NwAAAgF/AAEAAAAzAAAAPEhLRUlMRkdKQ0JNQkhPQ0dNQUpOTUVQRURCQUEuc21jY29ybWFj a0B0c3NnLm9yZz4AAAMABhBRkTiJAwAHEOgBAAADABAQAAAAAAMAERABAAAAHgAIEAEAAABlAAAA SEksSVdJU0hUT0lNUExFTUVOVEFTSVBTRVJWTEVUVEhBVFNVQlNDUklCRVNUT0RJRkZFUkVOVFVT RVJTVEhBVENBTlRIRU9SRVRJQ0FMTFlSRUNFSVZFR0VPR1JBUEhJQ0FMTAAAAAAA0A== ------=_NextPart_000_0216_01C2F77D.D1B751A0-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Mon Mar 31 09:20:55 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07066 for ; Mon, 31 Mar 2003 09:20:55 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2VEiBx07380 for sip-archive@odin.ietf.org; Mon, 31 Mar 2003 09:44:11 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2VEbSO06741; Mon, 31 Mar 2003 09:37:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2VDSeO01912 for ; Mon, 31 Mar 2003 08:28:40 -0500 Received: from web20503.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA05381 for ; Mon, 31 Mar 2003 08:04:55 -0500 (EST) Message-ID: <20030331130720.25612.qmail@web20503.mail.yahoo.com> Received: from [167.205.22.105] by web20503.mail.yahoo.com via HTTP; Mon, 31 Mar 2003 05:07:20 PST Date: Mon, 31 Mar 2003 05:07:20 -0800 (PST) From: Percy Tambunan To: sip@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Sip] request Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Does anyone have the SIP client and server program from the Columbia University? I really need that program for my Final Project. Thanks __________________________________________________ Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! http://platinum.yahoo.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Mon Mar 31 11:28:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13057 for ; Mon, 31 Mar 2003 11:28:05 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2VGpON17429 for sip-archive@odin.ietf.org; Mon, 31 Mar 2003 11:51:24 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2VGiaO17025; Mon, 31 Mar 2003 11:44:36 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2VGeFO16874 for ; Mon, 31 Mar 2003 11:40:15 -0500 Received: from mail4.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12708 for ; Mon, 31 Mar 2003 11:16:25 -0500 (EST) Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h2VGIfn4003649; Mon, 31 Mar 2003 11:18:41 -0500 (EST) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 31 Mar 2003 10:18:48 -0600 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A64609@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'Jussi.Turunen@nokia.com'" , sip@ietf.org Cc: Adam Roach Subject: RE: [Sip] Event header in responses Date: Mon, 31 Mar 2003 10:18:42 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , The bug you indicate (#677) is in regards to the question of how to match responses to their requests, not whether "Event" is allowed in responses. The short answer to your question, though, is that "Event" should not be present in responses. The "Event:" header in steps 6, 8, 10, and 12 of the example of event-lists-01 is an oversight. Thanks for finding it. That said, an implementation that receives an "Event" header in a response should silently discard it. /a > -----Original Message----- > From: Jussi.Turunen@nokia.com [mailto:Jussi.Turunen@nokia.com] > Sent: Monday, March 31, 2003 0:29 > To: sip@ietf.org > Cc: adam@dynamicsoft.com > Subject: [Sip] Event header in responses > > > Hi > > Bug 677 (http://www.sipwg.org/sipwg/show_bug.cgi?id=677) says > that there is confilicting text in RFC 3265 about Event > header in responses. The wording of the bug is not 100% > clear, but I assume that responses should not contain an > Event header. The reason for my question is that SIP Service > Examples-04 and shows no Event in responses, presence-10 call > flow example shows it, event-list-01 draft shows it > sometimes. What is the correct interpretation? > > Jussi > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Mon Mar 31 11:46:38 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13842 for ; Mon, 31 Mar 2003 11:46:38 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2VH9uQ19603 for sip-archive@odin.ietf.org; Mon, 31 Mar 2003 12:09:56 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2VH3FO18116; Mon, 31 Mar 2003 12:03:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2VGxRO17826 for ; Mon, 31 Mar 2003 11:59:27 -0500 Received: from imr2.ericy.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13408 for ; Mon, 31 Mar 2003 11:35:38 -0500 (EST) Received: from mr5.exu.ericsson.se (mr5att.ericy.com [138.85.224.141]) by imr2.ericy.com (8.12.8/8.12.8) with ESMTP id h2VGbssB004106; Mon, 31 Mar 2003 10:37:54 -0600 (CST) Received: from noah.lmc.ericsson.se (noah.lmc.ericsson.se [142.133.1.1]) by mr5.exu.ericsson.se (8.12.8/8.12.8) with ESMTP id h2VGbrsJ024615; Mon, 31 Mar 2003 10:37:54 -0600 (CST) Received: from EAMMLEX034.lmc.ericsson.se (eammlex034.lmc.ericsson.se [142.133.1.134]) by noah.lmc.ericsson.se (8.11.2/8.9.2) with ESMTP id h2VGbrh21627; Mon, 31 Mar 2003 11:37:53 -0500 (EST) Received: by eammlex034.lmc.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Mon, 31 Mar 2003 11:37:53 -0500 Message-ID: <32CD630F6CBED411AE180008C7894CBC0C037E12@lmc37.lmc.ericsson.se> From: "George Foti (LMC)" To: "'Jonathan Rosenberg'" , sip@ietf.org Date: Mon, 31 Mar 2003 11:37:46 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2F7A3.DBFD0F80" Subject: [Sip] Question Caller Preferences 08 draft Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , 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_01C2F7A3.DBFD0F80 Content-Type: text/plain; charset="ISO-8859-1" Quoting the 08 draft section 7.4 (Matching): Next, the proxy applies the predicates associated with the Accept-Contact header field. For each contact that remains in the target set, the proxy constructs a matching set, Ms. Initially, this set contains all of the Accept-Contact predicates. Each of those predicates is examined. It is matched to the contact predicate using the matching operation of RFC 2533 [2]. If the result is not a match, and the Accept-Contact predicate had its require flag set, the URI corresponding to that contact predicate is discarded from the contact set. If the result is not a match, but the Accept-Contact predicate removed from the target set. My question relates to the last statement in the above paragraph. The objective of that step, as I understand it, is to remove from the set all predicates, that don't have an equivalent in the contact. This step seems to be redundant, as it would not have an impact on the score, since it would not change the score anyway (based on the way the score is calculated) Is my understanding correct? My next question relates to the usage of the cancel-directive. Quoting the Draft : cancel-directive: This type of directive indicates whether the caller would like each proxy server to send a CANCEL request downstream ("cancel") in response to a 200 OK from the downstream server (which is the normal mode of operation, making it somewhat redundant), or whether this function should be left to the caller ("no-cancel"). If a proxy receives a request with this parameter set to "no- cancel", it SHOULD NOT CANCEL any outstanding branches on receipt of a 2xx. However, it would still send CANCEL on any outstanding branches on receipt of a 6xx. The strength SHOULD NOT makes it unclear as to how the UAC can decide on what to do, even if the proxy understands caller preferences. Rgds/gf ------_=_NextPart_001_01C2F7A3.DBFD0F80 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Question Caller Preferences 08 draft

Quoting the 08 draft  section = 7.4 (Matching):

Next, the proxy applies the = predicates associated with the Accept-Contact header field. For each = contact that remains in the target set, the proxy constructs a matching = set, Ms. Initially, this set contains all of the Accept-Contact = predicates. Each of those predicates is examined. It is matched to the = contact predicate using the matching operation of RFC 2533 [2]. If the = result is not a match, and the Accept-Contact predicate had its require = flag set, the URI corresponding to that contact predicate is discarded = from the contact set. If the result is not a match, but the = Accept-Contact predicate removed from the target set.

My question relates to the last = statement in the above paragraph.
The objective of that step, as = I understand it, is to remove from the set all predicates, that don't = have an equivalent in the contact.

This step seems to be redundant, = as it would not have an impact on the score, since it would not change = the score anyway (based on the way the score is calculated)

Is my understanding = correct?

My next question relates to the = usage of the cancel-directive.
Quoting the Draft :

cancel-directive: This type of = directive indicates whether the
           &= nbsp; caller would like each proxy server to send a CANCEL
           &= nbsp; request downstream ("cancel") in response to a 200 OK = from
           &= nbsp; the downstream server (which is the normal mode of
           &= nbsp; operation, making it somewhat redundant), or whether this
           &= nbsp; function should be left to the caller ("no-cancel"). If = a
           &= nbsp; proxy receives a request with this parameter set to = "no-
           &= nbsp; cancel", it SHOULD NOT CANCEL any outstanding branches = on
           &= nbsp; receipt of a 2xx. However, it would still send CANCEL on
           &= nbsp; any outstanding branches on receipt of a 6xx.

The strength SHOULD NOT makes it = unclear as to how the UAC can decide on what to do, even if the proxy = understands caller preferences.

Rgds/gf
 

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