From nobody Mon Jun 2 09:26:36 2014 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3F951A0234 for ; Mon, 2 Jun 2014 09:26:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.821 X-Spam-Level: X-Spam-Status: No, score=-1.821 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9QB6wFJlIL5N for ; Mon, 2 Jun 2014 09:26:33 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44E621A037C for ; Mon, 2 Jun 2014 09:26:33 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id k48so5515381wev.17 for ; Mon, 02 Jun 2014 09:26:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-type:content-transfer-encoding :subject:message-id:date:to:mime-version; bh=rDIUMMzqaCtTJ5tjUrfiex3JK3z443bo10wrZN3Wfy8=; b=OcQgaBFgwe715lWCmOW8+2jPlYue3qLwDv+S4BrZD+ZEIpFi5GWRDxnkgBNXBegOIi NMPjaOk3z5/AxFyCicDJU67wAUA6EIKYKkMd7jEwbNH7/iNjbitVK40SJWfo0N/ga/+k rOMQ83rEpP4F8iWsxZfroO7wkY2YeGlBuTEL/P307RzPdBoxj3iOJwKd6YMMByd7igkl y558svWQfge1Bg2z5DfrcNzgMeKZNmHTV4DPVPs/40JA08EDoM+Yvg5MTyblx0jwhRsb Mpf4/qQ+oNjRUTPx0SXBiuI58yZolpYw+jLGDMSl1mCFTWIunsh8cArxvCkPNSgMYnNo Ex1g== X-Gm-Message-State: ALoCoQkksIbtiktA7fDYbP7h3zZ4gDecS8C+M+syrFpAoVN4zNas+J5fGmMfVhlHE0biUxyFJM+r X-Received: by 10.195.12.134 with SMTP id eq6mr51248718wjd.14.1401726385831; Mon, 02 Jun 2014 09:26:25 -0700 (PDT) Received: from [10.33.192.21] (neustargw.va.neustar.com. [209.173.53.233]) by mx.google.com with ESMTPSA id ge6sm21436163wic.0.2014.06.02.09.26.24 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 02 Jun 2014 09:26:25 -0700 (PDT) From: Brian Rosen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <6DDC29BF-7BA0-4AF4-BCD8-645B2D8F4D1A@brianrosen.net> Date: Mon, 2 Jun 2014 12:26:29 -0400 To: siprec@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/siprec/INFlaeQS859mDzit53S8-_MvdTg Subject: [siprec] Working Group Last Call on -protocol X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 16:26:34 -0000 This email announces a 3 week working group last call on = draft-ietf-siprec-protocol-12. Please send comments to the list. If you have read the latest draft, = and believe it is ready to publish, please say so affirmatively. Chairs= From nobody Tue Jun 3 11:38:51 2014 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1284C1A0262 for ; Tue, 3 Jun 2014 11:38:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.035 X-Spam-Level: X-Spam-Status: No, score=-0.035 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_16=0.6, J_CHICKENPOX_18=0.6, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Wkpy9OSRUyN for ; Tue, 3 Jun 2014 11:38:48 -0700 (PDT) Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:80]) by ietfa.amsl.com (Postfix) with ESMTP id BA99D1A0249 for ; Tue, 3 Jun 2014 11:38:47 -0700 (PDT) Received: from omta14.westchester.pa.mail.comcast.net ([76.96.62.60]) by qmta08.westchester.pa.mail.comcast.net with comcast id 9sgD1o0011HzFnQ58uehVk; Tue, 03 Jun 2014 18:38:41 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta14.westchester.pa.mail.comcast.net with comcast id 9ueh1o00Q3ZTu2S3aueh7h; Tue, 03 Jun 2014 18:38:41 +0000 Message-ID: <538E1631.9030607@alum.mit.edu> Date: Tue, 03 Jun 2014 14:38:41 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: siprec@ietf.org References: <6DDC29BF-7BA0-4AF4-BCD8-645B2D8F4D1A@brianrosen.net> In-Reply-To: <6DDC29BF-7BA0-4AF4-BCD8-645B2D8F4D1A@brianrosen.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1401820721; bh=PsuE7U420jE0CYFYPgQlKK4vmo9qSmkeT41pxAeE3Xc=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=OAtj0iwZK8Vlph0lJ9Sq/WDt9h+EeLuXSEIiclo0hjQQzjhwSWN40kPfLr88etb4w pv8W1vChE4y1zISaN/jzyRwfN3KGTAAnw5hBvfDRDBT2FLqbDsK82IPstbt5/D4OBo FZ/Skn0sD2fCSSbJGugF0p8JoxCnmj/0hvbxtpTjqnVCwFye4f8LjlCK3X46V3f+n0 kBqmhXB5MJJWBvUBWdpVR7cQRC0Kg4MDsmR7Rl/w1Jy1rwJr+CpxBJ2BxLdfgvLFEM OVbmz7fsYG8AqO4ui8rSq4aQxi1vFM7NE+uc9XpJXnX+ma0/zApmu3lrlhW3ZlN3jN /fMNRpnvrtmSw== Archived-At: http://mailarchive.ietf.org/arch/msg/siprec/UJUzKjnE_oLm97S4seYgnmPq-LU Subject: Re: [siprec] Working Group Last Call on -protocol X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 18:38:49 -0000 I just did a reasonably careful review of the document. In general I think it is in very good shape. I found a few things that need fixing, or at least discussing: Section 6.1.2: We debated the language in this section extensively, and IMO we chose the proper level of requirement. But I anticipate we will have some (maybe a lot) of difficulty over this with the IESG - with some no doubt arguing that this isn't strong enough. I wonder if we ought to anticipate this, and include a note explaining our thinking. (The point of concern is for "in the absence ...) Or perhaps we should have a section on this in the Security Considerations section. Section 7.1.1.1: Upon reading this again, I realized that we don't say anything about media streams that don't have labels, or that have labels without a corresponding reference in the metadata. I guess the first question is whether we think this is an acceptable thing to do. IMO it is. This could be used to "park" a media stream that isn't currently needed for recording. Then it could be reused later. (Of course the SRS could choose to refuse such sessions, or set them to inactive.) While I understand the intent of the following sentence, it could be confusing: ... The SRC MUST NOT modify the RS media stream with a=inactive for SDP hold on the CS since this operation is reserved for pausing the RS media, however, an SRC can have a local policy to pause the RS media when the CS is placed on hold. The second half seems to almost contradict the first half. How about the following When a CS media stream is changed to/from inactive, the effect on the corresponding RS media stream is governed by SRC policy. The SRC MAY have a local policy to pause an RS media stream when the corresponding CS media stream is inactive, or it MAY leave the RS media stream as sendonly. Section 7.1.2: I wonder if: Whenever the recording indication needs to change, such as termination of recording, then the SRC MUST initiate a reINVITE or UPDATE to update the SDP a=record attribute. is a little too strong. Is it mandatory to notify that the state has changed from on->paused or paused->on? Editorial comment on following: on Recording is in progress. off No recording is in progress. paused Recording is in progress but media is paused. I think the terms should be set of from the definitions. E.g., on: Recording is in progress. off: No recording is in progress. paused: Recording is in progress but media is paused. Section 7.3.2: I suggest that the definitions of 'on', 'off', ... be revised as I suggested above for section 7.1.2. Section 8.2.1.2: When acting as a transcoding translator, an SRC MAY perform transcoding (e.g., from one codec to another), and this may result in a different rate of packets between what the SRC receives and what the SRC sends. Note that the SRC is transmitting on both CS and RS. I think the following would be clearer: When acting as a transcoding translator, an SRC MAY perform transcoding (e.g., from one codec to another), and this may result in a different rate of packets between what the SRC receives on the CS and what the SRC sends on the RS. Section 8.3.2: Last sentence in 2nd paragraph has a typo: In doing to, the SRC acts as an RTP mixer. s/In doing to/In doing so/ Firgure 10 also has a typo. The SSRC of the video session between SRC and SRS should be Sv, not Sa. Section 11.3: This content disposition is used for both metadata and for snapshot requests. But snapshot requests aren't mentioned here. Sections 11.5.1 and 11.5.2: Do we want these individual contact anmes and email addresses, or something more generic? The email address for Leon is no longer correct. Thanks, Paul On 6/2/14 12:26 PM, Brian Rosen wrote: > This email announces a 3 week working group last call on draft-ietf-siprec-protocol-12. > > Please send comments to the list. If you have read the latest draft, and believe it is ready to publish, please say so affirmatively. > > Chairs > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > From nobody Tue Jun 3 11:46:40 2014 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FF8A1A0260 for ; Tue, 3 Jun 2014 11:46:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1hH9anM-PrRs for ; Tue, 3 Jun 2014 11:46:37 -0700 (PDT) Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:64]) by ietfa.amsl.com (Postfix) with ESMTP id F415C1A0249 for ; Tue, 3 Jun 2014 11:46:36 -0700 (PDT) Received: from omta11.westchester.pa.mail.comcast.net ([76.96.62.36]) by qmta07.westchester.pa.mail.comcast.net with comcast id 9s8V1o0020mv7h057umX5x; Tue, 03 Jun 2014 18:46:31 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta11.westchester.pa.mail.comcast.net with comcast id 9umW1o00w3ZTu2S3XumWKi; Tue, 03 Jun 2014 18:46:31 +0000 Message-ID: <538E1806.9040908@alum.mit.edu> Date: Tue, 03 Jun 2014 14:46:30 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: siprec@ietf.org References: <20140528220324.16934.76369.idtracker@ietfa.amsl.com> <53865EEC.7000605@alum.mit.edu> In-Reply-To: <53865EEC.7000605@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1401821191; bh=NDdOmu79Q7iuRUA8vTp0roL98gdB3eLM0OyS1NoVPqY=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=sY7bznP2FUvkFJ4fgF4h4QWVeo/HvwAZOI/oq+Ioz72+uWFF7msWfbR8Ka1/R+bqz 6j21H2Jl3tM27vlPiYkm3r+dHAtt6MxioLtjJfuJ3UmyfyS5/g+3EwN9s4p1K8ytgo LJLm2BIc/Tc1OEb0U8UHMZfzm6WfwpjF99lrM6mJX6Vxw1QqQoe2Lm5Jfml4apTjN+ ldus3r3LPVOJRm5OihjGqLGt8n5RXNvNroDr2tux829Gvga27XrtMMZfuR4AtKszpK ceYnfclgSSgU0rK6EqBypRsOd46RfnDwuFIlh0w+iTWwxxJB2eDEZSvcE3hyUisu72 MbsSIiD2V8O2A== Archived-At: http://mailarchive.ietf.org/arch/msg/siprec/x7r0OsAcVQ-G4jRe3xOneHmKYeg Subject: Re: [siprec] New Version Notification for draft-yan-siprec-msrp-recording-01.txt X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 18:46:38 -0000 Can I get some people in the wg to review and comment on this version? Thanks, Paul On 5/28/14 6:10 PM, Paul Kyzivat wrote: > I've submitted a revised version of the msrp recording draft. > This one is substantially fleshed out. It certainly needs more tweaking, > but is complete enough that you should be able to make meaningful > comments on the approach. > > Thanks, > Paul > > > -------- Original Message -------- > Subject: New Version Notification for > draft-yan-siprec-msrp-recording-01.txt > Date: Wed, 28 May 2014 15:03:24 -0700 > From: internet-drafts@ietf.org > To: Michael Yan , "Paul H. Kyzivat" > , "Michael Yan" , > "Paul Kyzivat" > > > A new version of I-D, draft-yan-siprec-msrp-recording-01.txt > has been successfully submitted by Paul H. Kyzivat and posted to the > IETF repository. > > Name: draft-yan-siprec-msrp-recording > Revision: 01 > Title: Overview for MSRP Recording based on SIPREC > Document date: 2014-05-28 > Group: Individual Submission > Pages: 9 > URL: > http://www.ietf.org/internet-drafts/draft-yan-siprec-msrp-recording-01.txt > Status: https://datatracker.ietf.org/doc/draft-yan-siprec-msrp-recording/ > Htmlized: http://tools.ietf.org/html/draft-yan-siprec-msrp-recording-01 > Diff: http://www.ietf.org/rfcdiff?url2=draft-yan-siprec-msrp-recording-01 > > Abstract: > SIPREC is capable of recording interactive text media that is > transmitted via RTP. However that format is not commonly used for > message or chat scenarios. There is also a need for recording text > media carried via MSRP. One case of note is exchange of text between > hearing-impaired users and emergence service bureaus. Also, > recording support is needed for MSRP used in chat conferences and > multimedia conferences. > > This document describes how to achieve MSRP channel recording within > the mechanism of SIP Recording (SIPREC). > > > > > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > > > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > From nobody Wed Jun 11 15:30:20 2014 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AB8F1A02ED; Wed, 11 Jun 2014 15:30:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jykzrsm9m4Xk; Wed, 11 Jun 2014 15:30:17 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B8C651B28A8; Wed, 11 Jun 2014 15:30:16 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.5.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140611223016.21924.52450.idtracker@ietfa.amsl.com> Date: Wed, 11 Jun 2014 15:30:16 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/siprec/pD5_xj_ai7UaizzPR1rL_YnrjdQ Cc: siprec WG Subject: [siprec] WG Action: Rechartered SIP Recording (siprec) X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.15 List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 22:30:19 -0000 The SIP Recording (siprec) working group in the Real-time Applications and Infrastructure Area of the IETF has been rechartered. For additional information please contact the Area Directors or the WG Chairs. SIP Recording (siprec) ------------------------------------------------ Current Status: Active WG Chairs: Brian Rosen Andrew Hutton Technical advisors: Peter Saint-Andre Assigned Area Director: Alissa Cooper Mailing list Address: siprec@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/siprec Archive: http://www.ietf.org/mail-archive/web/siprec/ Charter: The Session Recording Protocol (SIPREC) working group is chartered to define a SIP-based protocol for controlling a session (media) recorder. Session recording is a critical requirement in many business communications environments such as call centers and financial trading floors. In some of these environments, all calls must be recorded for regulatory and compliance reasons. In others, calls may be recorded for quality control, business analytics, or consumer protection. Recording is typically done by sending a copy of the media to the recording devices. The working group will determine requirements and produce a specification for a protocol that will manage delivery of media (including audio, video, MSRP instant message sessions, and real-time text), in SIP-based systems from an end-point that originates media, or that has access to it, to a recording device. PBX and recording vendors today implement proprietary, incompatible mechanisms to facilitate recording. A standard protocol will reduce the complexity and cost of providing such recording services. The Session Recording problem presents certain unique requirements that are not addressed in the current SIP protocol specification. These include requirements such as the need for a distinction between the session that is being recorded versus the session that has been established for recording. Privacy and security of conversations are significant concerns. The working group will make sure that any protocol specified addresses these concerns and includes mechanisms to alert users to the fact that a session they are participating in is being recorded. In addition the working group will take account of RFC 7258 concerning pervasive monitoring. The working group must take care that the session recording requirements and protocol does not conflict with the IETF statement on wiretapping contained in RFC 2804. The SIPREC Working Group will thoroughly identify use cases, provide example system architectures and deployment scenarios, and define requirements. The scope of the activity includes: * Recorder Control * Session metadata content and format * Security mechanisms, including transport and media encryption * Privacy concerns, including end-user notification * Negotiation of recording media streams The group will define these issues and rationalize with IETF standards and practices. This includes encryption, NAT traversal, operations and manageability, SIP-enabled firewalls, authorization, and security. The group will produce: * Updated Requirements, Use Cases, Architecture draft * Specification for Session Recording Protocol Milestones: Done - Use Cases and Requirements to IESG as Informational RFC Done - Submit Architecture to IESG as Informational RFC Jul 2014 - Submit protocol draft to IESG as Proposed Standard RFC Sep 2014 - Submit Metadata model and format to IESG as Proposed Standard RFC Sep 2014 - Submit SIPREC Call Flows draft to IESG as an informational RFC. Dec 2014 - Conference Recording Use Cases and Requirements to IESG as Informational RFC Dec 2014 - Conference Recording Architecture to IESG as Informational RFC Dec 2014 - Protocol and metadata for MSRP recording to IESG as Proposed Standard RFC Feb 2015 - Protocol and metadata for using RTP media to record the sharing of applications, documents and screens to the IESG as Proposed Standard RFC From nobody Thu Jun 12 11:13:41 2014 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FDF81B28B1 for ; Wed, 11 Jun 2014 15:32:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YtV-7d1zs-7E for ; Wed, 11 Jun 2014 15:32:46 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 288BB1A030C for ; Wed, 11 Jun 2014 15:32:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: siprec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.5.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140611223245.17024.42181.idtracker@ietfa.amsl.com> Date: Wed, 11 Jun 2014 15:32:45 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/siprec/1T2jL_yapFudv32osALti-7CPF4 X-Mailman-Approved-At: Thu, 12 Jun 2014 11:13:38 -0700 Subject: [siprec] Milestones changed for siprec WG X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.15 List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 22:32:47 -0000 Changed milestone "Submit Architecture to IESG as Informational RFC", resolved as "Done". URL: http://datatracker.ietf.org/wg/siprec/charter/ From nobody Fri Jun 13 21:51:43 2014 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C01EC1B2B4D for ; Fri, 13 Jun 2014 21:51:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.552 X-Spam-Level: X-Spam-Status: No, score=-14.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a8UW29m5wM47 for ; Fri, 13 Jun 2014 21:51:41 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 183001A0342 for ; Fri, 13 Jun 2014 21:51:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5490; q=dns/txt; s=iport; t=1402721501; x=1403931101; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=jl+79n2NJaysTVh9ys3OF+SirdpVPYBian8IuutuqHE=; b=GgNCi+SH/bCb2+NaB+ImKW1/z1/8wRmqJmvjrufiPBPllCYhMy9ECbTp evuTv617PlYSdl2AKVwXvMAbr24MX3qtF/hUpXvCz3y8e08OAqP31dJ6S IA663MhWuUkdDNn+ubQGxFvJ/4TPIVm0iWbWvKOJL4f9iUhJslHGItU+J k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlQGAM3Tm1OtJA2M/2dsb2JhbABagw1SWYJspncBAQEBAQEFAZFlhmxRARlsFnWEAwEBAQQBAQExOhcEAgEIEQMBAgUoAgIlCx0IAgQBEgmIOQ2UPZwcBp8HF4EkhDmDU4RbAwEBHDoGgmmBUgSaPYFDiXyIGYM+bIELOQ X-IronPort-AV: E=Sophos;i="5.01,476,1400025600"; d="scan'208";a="333078005" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-6.cisco.com with ESMTP; 14 Jun 2014 04:51:40 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s5E4peNn015513 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sat, 14 Jun 2014 04:51:40 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.9]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0123.003; Fri, 13 Jun 2014 23:51:39 -0500 From: "Charles Eckel (eckelcu)" To: "Ram Mohan R (rmohanr)" , "siprec@ietf.org" Thread-Topic: [siprec] FIR vs. SIP INFO Thread-Index: AQHPRLInie4MPj/tQEKPU85/ePxHyptwPCgA Date: Sat, 14 Jun 2014 04:51:38 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.21.125.10] Content-Type: text/plain; charset="euc-kr" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/siprec/lxr7newhZRyeSsd0dDOMXQJUh3Q Subject: Re: [siprec] FIR vs. SIP INFO X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jun 2014 04:51:42 -0000 UmV2aXZpbmcgYSBzbGVlcGluZyB0aHJlYWQgoaYNCg0KVGhlIHNlbnNlIG9mIHRoZSByb29tLCBh cyBjYXB0dXJlZCBpbiB0aGUgbWVldGluZyBtaW51dGVzLCB3YXMgdGhhdCB3ZSBhZGQNCmEgcmVx dWlyZW1lbnQgb24gdGhlIFNSUyB0byBzdXBwb3J0IGJvdGggbWV0aG9kcy4gQ29udGludWluZyB0 aGUNCmRpc2N1c3Npb24gb24gdGhlIGxpc3QgcmVzdWx0ZWQgaW4gb25seSBvbmUgYWRkaXRpb24g Y29tbWVudCwgZnJvbSBSYW0sIGluDQpzdXBwb3J0IG9mIHRoaXMgcHJvcG9zYWwuDQpXaXRoIHRo aXMgaW4gbWluZCwgSSBwcm9wb3NlIHdlIGFwcGVuZCB0aGUgZm9sbG93aW5nIHRvIHNlY3Rpb24g OC4xLjcuMS4xOg0KDQoiVG8gbWFrZSBzdXJlIGEgY29tbW9uIG1lY2hhbmlzbSBleGlzdHMgYmV0 d2VlbiB0aGUgU1JDIGFuZCBTUlMsIHRoZSBTUlMNCk1VU1Qgc3VwcG9ydCBib3RoIG1lY2hhbmlz bXMgKEZJUiBhbmQgU0lQIElORk8pLCB1c2luZyBGSVIgd2hlbiBuZWdvdGlhdGVkDQpzdWNjZXNz ZnVsbHkgd2l0aCB0aGUgU1JDLCBhbmQgdXNpbmcgU0lQIElORk8gb3RoZXJ3aXNlLiINCg0KQ29t bWVudHMgYW5kIG90aGVyIGlkZWFzIHdlbGNvbWUuDQoNCkNoZWVycywNCkNoYXJsZXMNCg0KT24g My8yMC8xNCwgODowMyBQTSwgIlJhbSBNb2hhbiBSIChybW9oYW5yKSIgPHJtb2hhbnJAY2lzY28u Y29tPiB3cm90ZToNCg0KPkkgcHJlZmVyIG9wdGlvbiAyIGFzIG1hbmRhdG9yeSBzaW5jZSBTUlMg aXMgdGhlIG9uZSB0aGF0IGV2ZW50dWFsbHkgbG9va3MNCj5hdCB0aGUgbWVkaWEgYmVpbmcgcmVj b3JkZWQoUlRQKSBhbmQgaXMgdGhlIGJlc3Qgb25lIHRvIGRlY2lkZSBvbiB3aGV0aGVyDQo+dG8g Z2VuZXJhdGUgYSBGSVIgb3IgU0lQIElORk8uICBIb3dldmVyIHdlIG1heSBhbHNvIGFsbG93IGEg U1JDIHRvDQo+Z2VuZXJhdGUgYSBGSVIvU0lQIElORk8uIFNvIEkgcHJlZmVyIHRoYXQgd2UgY2Fu IGtlZXAgTVVTVCBmb3Igb3B0aW9uIDINCj5hbmQgTUFZIGZvciBvcHRpb24gMS4NCj4NCj5JIGhh dmUgYSBzbGlnaHRseSBkaWZmZXJlbnQgcXVlc3Rpb24gb24gdGhpcyAtDQo+RG8gd2Ugd2FudCBT UlMob3IgU1JDKSB0byBhbHdheXMgZ2VuZXJhdGUgYm90aCBGSVIgYW5kIFNJUCBJTkZPID8gVGhl cmUNCj5tYXkgYmUgY2FzZXMgd2hlcmUgZW5kcG9pbnQgKFVBKSBtYXkgc3VwcG9ydCBvbmUgb3Ig Ym90aCBvZiB0aGVtLiBJZiBhIFVBDQo+c3VwcG9ydHMgYm90aCBvZiB0aGVtIGl0IG1heSByZXN1 bHQgaW4gYSBjYXNlIHdoZXJlIFVBIG1heSByZS10cmFuc21pdCBJRFINCj5mcmFtZSB0d2ljZSAo b25lIG9uIHJlY2VpcHQgb2YgRklSIGFuZCBvdGhlciBvbiBvbiByZWNlaXB0IG9mIFNJUCBJTkZP KS4NCj5UaGlzIGlzIG9rIGluIHByaW5jaXBsZSBidXQgbWF5IGxlYWQgdG8gbW9yZSBuZXR3b3Jr IGNvbmdlc3Rpb24gZHVlIHRvDQo+YnVyc3R5IHRyYWZmaWMuIElzIHRoaXMgc29tZSB0aGluZyB3 ZSBzaG91bGQgd29ycnkgYWJvdXQgPw0KPg0KPlBlcmhhcHMgaWYgdGhlcmUgaXMgYSB3YXkgU1JT L1NSQyBjYW4gZmluZCB3aGF0IG1ldGhvZCB0aGUgVUEgcHJlZmVycyAoRklSDQo+b3IgU0lQIElO Rk8pIGl0IGNhbiBvbmx5IGdlbmVyYXRlIHRoYXQuDQo+DQo+UmFtDQo+DQo+DQo+LS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCj5Gcm9tOiAiQ2hhcmxlcyBFY2tlbCAgIChlY2tlbGN1KSIgPGVj a2VsY3VAY2lzY28uY29tPg0KPkRhdGU6IEZyaWRheSwgMjEgTWFyY2ggMjAxNCAyOjM0IGFtDQo+ VG86ICJzaXByZWNAaWV0Zi5vcmciIDxzaXByZWNAaWV0Zi5vcmc+DQo+U3ViamVjdDogW3NpcHJl Y10gRklSIHZzLiBTSVAgSU5GTw0KPg0KPj5UbyB0aGUgYmVzdCBvZiBteSBrbm93bGVkZ2UsIHRo aXMgaXMgdGhlIGxhc3Qgb3BlbiBpdGVtIGluIHRoZSBwcm90b2NvbA0KPj5kcmFmdC4gSGVyZSBp cyB0aGUgaW5mbyBmcm9tIHRoZSBzbGlkZSBwcmVzZW50ZWQgYXQgSUVURiA4OSBpbiBMb25kb246 DQo+Pg0KPj5GSVIgYW5kIFNJUCBJTkZPIHJlcXVpcmVtZW50cyBpbiBTUkMgYW5kL29yIFNSUw0K Pj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+U2VjdGlvbiA4LjEuNy4xLjEgU0lQIElORk8g Zm9yIEZJUg0KPj6hpyJYTUwgU2NoZW1hIGZvciBNZWRpYSBDb250cm9sqfcgW1JGQzUxNjgNCj4+ PGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzUxNjg+XSBkZWZpbmVzIGFuIEV4dGVuc2li bGUgTWFya3VwDQo+Pkxhbmd1YWdlIChYTUwpIFNjaGVtYSBmb3IgdmlkZW8gZmFzdCB1cGRhdGUu IEltcGxlbWVudGF0aW9ucyBhcmUNCj4+ZGlzY291cmFnZWQgZnJvbSB1c2luZyB0aGUgbWV0aG9k IGRlc2NyaWJlZCBleGNlcHQgZm9yIGJhY2t3YXJkDQo+PmNvbXBhdGliaWxpdHkgcHVycG9zZXMu IEltcGxlbWVudGF0aW9ucyBTSE9VTEQgdXNlIEZJUiBtZXNzYWdlcyBpbnN0ZWFkLg0KPj4NCj4+ TkVOQSBJQ0UtOCBldmVudCBmZWVkYmFjaywgZG8gd2UgbmVlZCB0byBzYXkgbW9yZT8gT3B0aW9u czoNCj4+MS5TUkMgTVVTVCBzdXBwb3J0IGJvdGggYW5kIHByb3ZpZGUgaW50ZXJ3b3JraW5nIHRv IHdoYXQgU1JTIHN1cHBvcnRzDQo+PihhbmQNCj4+YW4gVUEgdGhhdCBkb2VzIG5vdCBzdXBwb3J0 IGJvdGggTVVTVCBOT1QgdXNlIFNJUFJFQz8pDQo+PjIuU1JTIE1VU1Qgc3VwcG9ydCBib3RoIChh bmQgYWxsb3cgU1JDIHRvIHN1cHBvcnQgYm90aCBzaW11bHRhbmVvdXNseT8NCj4+QW5kDQo+Pmhv dyBkbyB5b3UgbmVnb3RpYXRpb24gdGhhdCA/KQ0KPj4zLlByb3ZpZGUgcmVjb21tZW5kYXRpb25z IGFuZCBsZWF2ZSBhcyBxdWFsaXR5IG9mIGltcGxlbWVudGF0aW9uIGRlY2lzaW9uDQo+PihhbmQg bGl2ZSB3aXRoIGludGVyb3BlcmFiaWxpdHkgaXNzdWVzPykNCj4+LS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NCj4+DQo+PkRpc2N1c3Npb24gaW4gcm9vbSAoZnJvbSBtaW51dGVzOg0KPj5o dHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvc2lwcmVjL2N1cnJlbnQvbXNnMDM5 MzQuaHRtbCkNCj4+LSBQYXVsIEsgLSBubyBicmFpbmVyLCBTUlMgaXMgdGhlIHBvd2VyZnVsIGJv eCAtIHRoYXQgaXMgdGhlIHBsYWNlIHRvIHB1dA0KPj5yZXF1aXJlbWVudHMgLSAyIGlzIHByZWZl cmFibGUgdG8gMSAtIDIgdnMuIDMsIEknbSBub3Qgc3VyZSwga2luZCBvZg0KPj5pbmNsaW5lZCBm b3IgMiBidXQgbm90IHN1cmUNCj4+LSBDaGFpcjogZGVmaW5pdGl2ZSBpcyBiZXN0IGZvciBpbXBs ZW1lbnRhdGlvbg0KPj4tIENoYXJsZXM6IG9wdGlvbiAzIGlzIG15IHN1Z2dlc3Rpb24gKGFzIHRo ZSBkcmFmdCBpcyksIGJ1dCBjb3VsZCBsaXZlDQo+PndpdGggb3B0aW9uIDIgLSB3b3VsZCBhcHBy ZWNpYXRlIHNvbWUgaGVscCB3aXRoIHRoZSB0ZXh0IC0gbmVlZCB0byB0aGluaw0KPj5hYm91dCB1 c2UgY2FzZXMgLSBpZiBhIFVBIGlzIGNhcGFibGUgb2YgZGVhbGluZyB3aXRoIGJvdGgsIGl0IGNh bg0KPj5zaW1wbGlmeQ0KPj5mb3IgdGhlIFNSUywgYnV0IGRlcGVuZHMgb24gY2FwYWJpbGl0aWVz IG9mIHRoZSBTUkMgYW5kIFNSUyAtIGlmIHdlIGNhbg0KPj5kbw0KPj5iZXR0ZXIgdGhhdCBpcyBn cmVhdA0KPj4tIENoYWlyOiBsZXQncyBoYXZlIG1vcmUgbGlzdCBkaXNjdXNzaW9uIGJlY2F1c2Ug bWlzc2luZyBwZW9wbGUgLSBidXQgaW4NCj4+ZmF2b3VyIG9mIGRvY3VtZW50aW5nIG9uZSBhbmQg Z2VuZXJhbGx5IGluIGZhdm91ciBvZiBoYXZpbmcgdGhlIHNlcnZlciBkbw0KPj50aGUgd29yayAt IHRlbnRhdGl2ZWx5IHRoaW5rIGdvaW5nIGluIHRoZSBkaXJlY3Rpb24gb2Ygb3B0aW9uIDINCj4+ DQo+PlRob3VnaHRzPw0KPj4NCj4+Q2hlZXJzLA0KPj5DaGFybGVzDQo+Pg0KPj5fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj5zaXByZWMgbWFpbGluZyBs aXN0DQo+PnNpcHJlY0BpZXRmLm9yZw0KPj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3NpcHJlYw0KPg0KDQo= From nobody Fri Jun 13 21:51:47 2014 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B2DB1B2B4D for ; Fri, 13 Jun 2014 21:51:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.952 X-Spam-Level: X-Spam-Status: No, score=-13.952 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_16=0.6, J_CHICKENPOX_18=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ODzToY5oMOU for ; Fri, 13 Jun 2014 21:51:43 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CEEE1A0342 for ; Fri, 13 Jun 2014 21:51:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6501; q=dns/txt; s=iport; t=1402721503; x=1403931103; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=f+sgUo/+i/Rbmz9b0l2OuESt8zKwp/UfxM3hxB1aY0o=; b=Rw5zA4h567j/6P7Ipve+I9wcwuidOUK5XtnvEvSkolfD03zjxDu9MQYi H/GGBo1lf4neDy/ZqQjsP9YD3TfZY8NeukDs/FBIklS//wv1Z3DHlVhQw kpbJBblUKAPVwV3lBj0GXrY5m77gCtS280ykqdg4hqYbCjRA06/Iu7qrk U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlEGABbUm1OtJV2P/2dsb2JhbABQCg6Cf1JZqWMBAQEBAQEFAZFlhmxRAYEFFnWEAwEBAQMBAQEBJEcQCwIBCA4KLicLJQIEARKIOggNz2kTBIVdiCAGCwEdOoRBBIoBjC2ED5NYgn1BgXc5 X-IronPort-AV: E=Sophos;i="5.01,476,1400025600"; d="scan'208";a="333069285" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-8.cisco.com with ESMTP; 14 Jun 2014 04:51:42 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s5E4pggD007048 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 14 Jun 2014 04:51:42 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.9]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0123.003; Fri, 13 Jun 2014 23:51:42 -0500 From: "Charles Eckel (eckelcu)" To: Paul Kyzivat , "siprec@ietf.org" Thread-Topic: [siprec] Working Group Last Call on -protocol Thread-Index: AQHPfn9sJIarrbBVDk6W4aliQaYYHJtgDOeAgA/O1IA= Date: Sat, 14 Jun 2014 04:51:40 +0000 Message-ID: References: <6DDC29BF-7BA0-4AF4-BCD8-645B2D8F4D1A@brianrosen.net> <538E1631.9030607@alum.mit.edu> In-Reply-To: <538E1631.9030607@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.21.125.10] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <1674A1FD227689428A777B83E9EC1C0F@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/siprec/ZxbEE8_a6HCUJ3DQ6FOqaD2_2Ao Subject: Re: [siprec] Working Group Last Call on -protocol X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jun 2014 04:51:45 -0000 Thanks for reviewing Paul. Please see inline. On 6/3/14, 11:38 AM, "Paul Kyzivat" wrote: >I just did a reasonably careful review of the document. >In general I think it is in very good shape. I found a few things that >need fixing, or at least discussing: > >Section 6.1.2: > >We debated the language in this section extensively, and IMO we chose >the proper level of requirement. But I anticipate we will have some >(maybe a lot) of difficulty over this with the IESG - with some no doubt >arguing that this isn't strong enough. > >I wonder if we ought to anticipate this, and include a note explaining >our thinking. (The point of concern is for "in the absence ...) Or >perhaps we should have a section on this in the Security Considerations >section. I see it as we are providing a new and hopefully better indication that recording is occurring. We are not removing or blocking existing indications, and we require the existing indications to still be used when the new indication cannot. We could add a warning that in the presence of an implementation that is not compliant with this specification recording may occur without any explicit indication, but that does not seem very useful. Did you have something else in mind? > >Section 7.1.1.1: > >Upon reading this again, I realized that we don't say anything about >media streams that don't have labels, or that have labels without a >corresponding reference in the metadata. > >I guess the first question is whether we think this is an acceptable >thing to do. IMO it is. This could be used to "park" a media stream that >isn't currently needed for recording. Then it could be reused later. (Of >course the SRS could choose to refuse such sessions, or set them to >inactive.) The way I read section 7.1.1, there must always be a label, regardless of whether the media line is actively being recorded. "The SRC sends recorded streams of participants to the SRS, and the SRC MUST provide a label attribute (a=3Dlabel), as per [RFC4574], on each media stream in order to identify the recorded stream with the rest of the metadata.=B2 Do we need to added complexity of having non-labelled media lines? > >While I understand the intent of the following sentence, it could be >confusing: > > ... The SRC MUST > NOT modify the RS media stream with a=3Dinactive for SDP hold on the C= S > since this operation is reserved for pausing the RS media, however, > an SRC can have a local policy to pause the RS media when the CS is > placed on hold. > >The second half seems to almost contradict the first half. How about the >following > > When a CS media stream is changed to/from inactive, the effect on the > corresponding RS media stream is governed by SRC policy. The SRC > MAY have a local policy to pause an RS media stream when the > corresponding CS media stream is inactive, or it MAY leave the RS > media stream as sendonly. Okay with me. > >Section 7.1.2: > >I wonder if: > > Whenever the recording > indication needs to change, such as termination of recording, then > the SRC MUST initiate a reINVITE or UPDATE to update the SDP a=3Drecor= d > attribute. > >is a little too strong. Is it mandatory to notify that the state has >changed from on->paused or paused->on? I think so. > >Editorial comment on following: > > on Recording is in progress. > > off No recording is in progress. > > paused Recording is in progress but media is paused. > >I think the terms should be set of from the definitions. E.g., > > on: Recording is in progress. > > off: No recording is in progress. > > paused: Recording is in progress but media is paused. Good idea. > >Section 7.3.2: > >I suggest that the definitions of 'on', 'off', ... be revised as I >suggested above for section 7.1.2. Sounds good. > >Section 8.2.1.2: > > When acting as a transcoding translator, an SRC MAY perform > transcoding (e.g., from one codec to another), and this may result in > a different rate of packets between what the SRC receives and what > the SRC sends. > >Note that the SRC is transmitting on both CS and RS. I think the >following would be clearer: > > When acting as a transcoding translator, an SRC MAY perform > transcoding (e.g., from one codec to another), and this may result in > a different rate of packets between what the SRC receives on the CS > and what the SRC sends on the RS. I like it. > >Section 8.3.2: > >Last sentence in 2nd paragraph has a typo: > > In doing to, the > SRC acts as an RTP mixer. > >s/In doing to/In doing so/ Good catch. > >Firgure 10 also has a typo. The SSRC of the video session between SRC >and SRS should be Sv, not Sa. Your comment has a type (s/Firgure/Figure), so I propose we leave it as is. Just kidding. VERY good catch. > >Section 11.3: > >This content disposition is used for both metadata and for snapshot >requests. But snapshot requests aren't mentioned here. How about this: OLD recording-session the body describes the metadata information about the recording session NEW recording-session: the body describes either: - the metadata information about the recording session or - the reason for a metadata snapshot request as determined by the MIME value indicated in the Content-Type (see section 11.4) > >Sections 11.5.1 and 11.5.2: > >Do we want these individual contact anmes and email addresses, or >something more generic? The email address for Leon is no longer correct. We can and should update Leon=B9s address to match that in the author list. Not sure what to do beyond that. Cheers, Charles > Thanks, > Paul > >On 6/2/14 12:26 PM, Brian Rosen wrote: >> This email announces a 3 week working group last call on >>draft-ietf-siprec-protocol-12. >> >> Please send comments to the list. If you have read the latest draft, >>and believe it is ready to publish, please say so affirmatively. >> >> Chairs >> _______________________________________________ >> siprec mailing list >> siprec@ietf.org >> https://www.ietf.org/mailman/listinfo/siprec >> > >_______________________________________________ >siprec mailing list >siprec@ietf.org >https://www.ietf.org/mailman/listinfo/siprec From nobody Thu Jun 26 09:53:05 2014 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0448E1B27D9 for ; Thu, 26 Jun 2014 09:53:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tF13NmJGT6XK for ; Thu, 26 Jun 2014 09:52:55 -0700 (PDT) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:40]) by ietfa.amsl.com (Postfix) with ESMTP id AE1C81A04B0 for ; Thu, 26 Jun 2014 09:32:26 -0700 (PDT) Received: from omta09.westchester.pa.mail.comcast.net ([76.96.62.20]) by qmta04.westchester.pa.mail.comcast.net with comcast id K2xb1o00B0SCNGk544YSyL; Thu, 26 Jun 2014 16:32:26 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta09.westchester.pa.mail.comcast.net with comcast id K4YS1o0043ZTu2S3V4YSdg; Thu, 26 Jun 2014 16:32:26 +0000 Message-ID: <53AC4B1A.9050707@alum.mit.edu> Date: Thu, 26 Jun 2014 12:32:26 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: siprec@ietf.org References: <20140528220324.16934.76369.idtracker@ietfa.amsl.com> <53865EEC.7000605@alum.mit.edu> <538E1806.9040908@alum.mit.edu> In-Reply-To: <538E1806.9040908@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1403800346; bh=EQWxaocnFJtsszhfLWGM36fPUMYuzQZ1yUgRE1ui7Rg=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=K3BOY9GDAwnjZnnanVqOscws5XGNzm9Hqd7Bqv82f7CzHX+Q5lIRZe/kM/TXdCw3C f+Gwsy80jMwA6NAPAatPnZe6dAdgEeUkptmhw/qged3q7Jsmn9OMFgJS4bsL0iDudB 1nVFw6257MuhM/AFlLaETnbC/MVJwIaDlnh1SsPZMSid6gS7X4FusWu3wdWyx3eoAW bf4aJDwLp7Q6xEtUJin8i7Aos2Wu6qdk8Go1JP57b1ZV0Ol7G9ZaFyYQy/LKsakecB P3zzIsqIlt+OGq8m20QQaDI8N+2NxwVl3kO/K0lc5743P2bOsys8mE9+f+9YQ6neoC O/UvjsZgeTQ+w== Archived-At: http://mailarchive.ietf.org/arch/msg/siprec/EZMNfTHgML8D6gVFspV1EEq66R0 Subject: Re: [siprec] New Version Notification for draft-yan-siprec-msrp-recording-01.txt X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2014 16:53:00 -0000 Trying one more time. Please!!! On 6/3/14 2:46 PM, Paul Kyzivat wrote: > Can I get some people in the wg to review and comment on this version? > > Thanks, > Paul > > On 5/28/14 6:10 PM, Paul Kyzivat wrote: >> I've submitted a revised version of the msrp recording draft. >> This one is substantially fleshed out. It certainly needs more tweaking, >> but is complete enough that you should be able to make meaningful >> comments on the approach. >> >> Thanks, >> Paul >> >> >> -------- Original Message -------- >> Subject: New Version Notification for >> draft-yan-siprec-msrp-recording-01.txt >> Date: Wed, 28 May 2014 15:03:24 -0700 >> From: internet-drafts@ietf.org >> To: Michael Yan , "Paul H. Kyzivat" >> , "Michael Yan" , >> "Paul Kyzivat" >> >> >> A new version of I-D, draft-yan-siprec-msrp-recording-01.txt >> has been successfully submitted by Paul H. Kyzivat and posted to the >> IETF repository. >> >> Name: draft-yan-siprec-msrp-recording >> Revision: 01 >> Title: Overview for MSRP Recording based on SIPREC >> Document date: 2014-05-28 >> Group: Individual Submission >> Pages: 9 >> URL: >> http://www.ietf.org/internet-drafts/draft-yan-siprec-msrp-recording-01.txt >> >> Status: https://datatracker.ietf.org/doc/draft-yan-siprec-msrp-recording/ >> Htmlized: http://tools.ietf.org/html/draft-yan-siprec-msrp-recording-01 >> Diff: http://www.ietf.org/rfcdiff?url2=draft-yan-siprec-msrp-recording-01 >> >> Abstract: >> SIPREC is capable of recording interactive text media that is >> transmitted via RTP. However that format is not commonly used for >> message or chat scenarios. There is also a need for recording text >> media carried via MSRP. One case of note is exchange of text between >> hearing-impaired users and emergence service bureaus. Also, >> recording support is needed for MSRP used in chat conferences and >> multimedia conferences. >> >> This document describes how to achieve MSRP channel recording within >> the mechanism of SIP Recording (SIPREC). >> >> >> >> >> >> >> Please note that it may take a couple of minutes from the time of >> submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> The IETF Secretariat >> >> >> >> >> _______________________________________________ >> siprec mailing list >> siprec@ietf.org >> https://www.ietf.org/mailman/listinfo/siprec >> > > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > From nobody Sat Jun 28 09:54:11 2014 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 046751A037A for ; Sat, 28 Jun 2014 09:54:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.552 X-Spam-Level: X-Spam-Status: No, score=-14.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3vvmJjyx4o02 for ; Sat, 28 Jun 2014 09:54:07 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75B511A037B for ; Sat, 28 Jun 2014 09:54:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6048; q=dns/txt; s=iport; t=1403974447; x=1405184047; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=IGK6kPaO48ymIOyHKeoqGPrfYByeqWkip2BlKcVQO4s=; b=eN3wf6KzeW9JtydgDp14tytX7eVgOm4+gxM+unmaHKm1lZre75DP8UAa xeXCp3KX21p8T1DkwrjognLuszNQ2L/MKdw21Mio3NYva9l8FbCyFMBOI QynTetEsvxHcoGaiwmVdnkntQ2rYlarCHwV8JLfEF8iQycpG6cpxvC/Q4 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFAA/yrlOtJA2N/2dsb2JhbABagw1SWoJuulCGbVMBGXAWdYQDAQEBBAEBATE6FwQCAQgRAwECAQQoAgIlCx0IAgQBEgmIOQ2MG5wdBp0dF4EliCaEZgMBARw6BoJrgVIFml2BRooIiC2DQmyBCzk X-IronPort-AV: E=Sophos;i="5.01,567,1400025600"; d="scan'208";a="56710932" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-5.cisco.com with ESMTP; 28 Jun 2014 16:54:06 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s5SGs6WV001015 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sat, 28 Jun 2014 16:54:06 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.243]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0123.003; Sat, 28 Jun 2014 11:54:06 -0500 From: "Ram Mohan R (rmohanr)" To: "Charles Eckel (eckelcu)" , "siprec@ietf.org" Thread-Topic: [siprec] FIR vs. SIP INFO Thread-Index: AQHPkvGSO9Rqq9IU4kegQwC2Sr79Xw== Date: Sat, 28 Jun 2014 16:54:05 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.65.41.170] Content-Type: text/plain; charset="euc-kr" Content-ID: <6E8B8D99A307A64AA2C66C4926B4F918@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/siprec/eQewRwauZaYHxITQvOY6MH_IR-k Subject: Re: [siprec] FIR vs. SIP INFO X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jun 2014 16:54:10 -0000 UHJvcG9zZWQgdGV4dCBsb29rcyBnb29kIHRvIG1lLg0KDQpSYW0NCg0KLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCkZyb206ICJDaGFybGVzIEVja2VsICAgKGVja2VsY3UpIiA8ZWNrZWxjdUBj aXNjby5jb20+DQpEYXRlOiBTYXR1cmRheSwgMTQgSnVuZSAyMDE0IDEwOjIxIGFtDQpUbzogUmFt IE1vaGFuIFJhdmluZHJhbmF0aCA8cm1vaGFuckBjaXNjby5jb20+LCAic2lwcmVjQGlldGYub3Jn Ig0KPHNpcHJlY0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbc2lwcmVjXSBGSVIgdnMuIFNJUCBJ TkZPDQoNCj5SZXZpdmluZyBhIHNsZWVwaW5nIHRocmVhZCChpg0KPg0KPlRoZSBzZW5zZSBvZiB0 aGUgcm9vbSwgYXMgY2FwdHVyZWQgaW4gdGhlIG1lZXRpbmcgbWludXRlcywgd2FzIHRoYXQgd2Ug YWRkDQo+YSByZXF1aXJlbWVudCBvbiB0aGUgU1JTIHRvIHN1cHBvcnQgYm90aCBtZXRob2RzLiBD b250aW51aW5nIHRoZQ0KPmRpc2N1c3Npb24gb24gdGhlIGxpc3QgcmVzdWx0ZWQgaW4gb25seSBv bmUgYWRkaXRpb24gY29tbWVudCwgZnJvbSBSYW0sIGluDQo+c3VwcG9ydCBvZiB0aGlzIHByb3Bv c2FsLg0KPldpdGggdGhpcyBpbiBtaW5kLCBJIHByb3Bvc2Ugd2UgYXBwZW5kIHRoZSBmb2xsb3dp bmcgdG8gc2VjdGlvbiA4LjEuNy4xLjE6DQo+DQo+IlRvIG1ha2Ugc3VyZSBhIGNvbW1vbiBtZWNo YW5pc20gZXhpc3RzIGJldHdlZW4gdGhlIFNSQyBhbmQgU1JTLCB0aGUgU1JTDQo+TVVTVCBzdXBw b3J0IGJvdGggbWVjaGFuaXNtcyAoRklSIGFuZCBTSVAgSU5GTyksIHVzaW5nIEZJUiB3aGVuIG5l Z290aWF0ZWQNCj5zdWNjZXNzZnVsbHkgd2l0aCB0aGUgU1JDLCBhbmQgdXNpbmcgU0lQIElORk8g b3RoZXJ3aXNlLiINCj4NCj5Db21tZW50cyBhbmQgb3RoZXIgaWRlYXMgd2VsY29tZS4NCj4NCj5D aGVlcnMsDQo+Q2hhcmxlcw0KPg0KPk9uIDMvMjAvMTQsIDg6MDMgUE0sICJSYW0gTW9oYW4gUiAo cm1vaGFucikiIDxybW9oYW5yQGNpc2NvLmNvbT4gd3JvdGU6DQo+DQo+PkkgcHJlZmVyIG9wdGlv biAyIGFzIG1hbmRhdG9yeSBzaW5jZSBTUlMgaXMgdGhlIG9uZSB0aGF0IGV2ZW50dWFsbHkgbG9v a3MNCj4+YXQgdGhlIG1lZGlhIGJlaW5nIHJlY29yZGVkKFJUUCkgYW5kIGlzIHRoZSBiZXN0IG9u ZSB0byBkZWNpZGUgb24gd2hldGhlcg0KPj50byBnZW5lcmF0ZSBhIEZJUiBvciBTSVAgSU5GTy4g IEhvd2V2ZXIgd2UgbWF5IGFsc28gYWxsb3cgYSBTUkMgdG8NCj4+Z2VuZXJhdGUgYSBGSVIvU0lQ IElORk8uIFNvIEkgcHJlZmVyIHRoYXQgd2UgY2FuIGtlZXAgTVVTVCBmb3Igb3B0aW9uIDINCj4+ YW5kIE1BWSBmb3Igb3B0aW9uIDEuDQo+Pg0KPj5JIGhhdmUgYSBzbGlnaHRseSBkaWZmZXJlbnQg cXVlc3Rpb24gb24gdGhpcyAtDQo+PkRvIHdlIHdhbnQgU1JTKG9yIFNSQykgdG8gYWx3YXlzIGdl bmVyYXRlIGJvdGggRklSIGFuZCBTSVAgSU5GTyA/IFRoZXJlDQo+Pm1heSBiZSBjYXNlcyB3aGVy ZSBlbmRwb2ludCAoVUEpIG1heSBzdXBwb3J0IG9uZSBvciBib3RoIG9mIHRoZW0uIElmIGEgVUEN Cj4+c3VwcG9ydHMgYm90aCBvZiB0aGVtIGl0IG1heSByZXN1bHQgaW4gYSBjYXNlIHdoZXJlIFVB IG1heSByZS10cmFuc21pdA0KPj5JRFINCj4+ZnJhbWUgdHdpY2UgKG9uZSBvbiByZWNlaXB0IG9m IEZJUiBhbmQgb3RoZXIgb24gb24gcmVjZWlwdCBvZiBTSVAgSU5GTykuDQo+PlRoaXMgaXMgb2sg aW4gcHJpbmNpcGxlIGJ1dCBtYXkgbGVhZCB0byBtb3JlIG5ldHdvcmsgY29uZ2VzdGlvbiBkdWUg dG8NCj4+YnVyc3R5IHRyYWZmaWMuIElzIHRoaXMgc29tZSB0aGluZyB3ZSBzaG91bGQgd29ycnkg YWJvdXQgPw0KPj4NCj4+UGVyaGFwcyBpZiB0aGVyZSBpcyBhIHdheSBTUlMvU1JDIGNhbiBmaW5k IHdoYXQgbWV0aG9kIHRoZSBVQSBwcmVmZXJzDQo+PihGSVINCj4+b3IgU0lQIElORk8pIGl0IGNh biBvbmx5IGdlbmVyYXRlIHRoYXQuDQo+Pg0KPj5SYW0NCj4+DQo+Pg0KPj4tLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPj5Gcm9tOiAiQ2hhcmxlcyBFY2tlbCAgIChlY2tlbGN1KSIgPGVja2Vs Y3VAY2lzY28uY29tPg0KPj5EYXRlOiBGcmlkYXksIDIxIE1hcmNoIDIwMTQgMjozNCBhbQ0KPj5U bzogInNpcHJlY0BpZXRmLm9yZyIgPHNpcHJlY0BpZXRmLm9yZz4NCj4+U3ViamVjdDogW3NpcHJl Y10gRklSIHZzLiBTSVAgSU5GTw0KPj4NCj4+PlRvIHRoZSBiZXN0IG9mIG15IGtub3dsZWRnZSwg dGhpcyBpcyB0aGUgbGFzdCBvcGVuIGl0ZW0gaW4gdGhlIHByb3RvY29sDQo+Pj5kcmFmdC4gSGVy ZSBpcyB0aGUgaW5mbyBmcm9tIHRoZSBzbGlkZSBwcmVzZW50ZWQgYXQgSUVURiA4OSBpbiBMb25k b246DQo+Pj4NCj4+PkZJUiBhbmQgU0lQIElORk8gcmVxdWlyZW1lbnRzIGluIFNSQyBhbmQvb3Ig U1JTDQo+Pj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+PlNlY3Rpb24gOC4xLjcuMS4xIFNJ UCBJTkZPIGZvciBGSVINCj4+PqGnIlhNTCBTY2hlbWEgZm9yIE1lZGlhIENvbnRyb2yp9yBbUkZD NTE2OA0KPj4+PGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzUxNjg+XSBkZWZpbmVzIGFu IEV4dGVuc2libGUgTWFya3VwDQo+Pj5MYW5ndWFnZSAoWE1MKSBTY2hlbWEgZm9yIHZpZGVvIGZh c3QgdXBkYXRlLiBJbXBsZW1lbnRhdGlvbnMgYXJlDQo+Pj5kaXNjb3VyYWdlZCBmcm9tIHVzaW5n IHRoZSBtZXRob2QgZGVzY3JpYmVkIGV4Y2VwdCBmb3IgYmFja3dhcmQNCj4+PmNvbXBhdGliaWxp dHkgcHVycG9zZXMuIEltcGxlbWVudGF0aW9ucyBTSE9VTEQgdXNlIEZJUiBtZXNzYWdlcyBpbnN0 ZWFkLg0KPj4+DQo+Pj5ORU5BIElDRS04IGV2ZW50IGZlZWRiYWNrLCBkbyB3ZSBuZWVkIHRvIHNh eSBtb3JlPyBPcHRpb25zOg0KPj4+MS5TUkMgTVVTVCBzdXBwb3J0IGJvdGggYW5kIHByb3ZpZGUg aW50ZXJ3b3JraW5nIHRvIHdoYXQgU1JTIHN1cHBvcnRzDQo+Pj4oYW5kDQo+Pj5hbiBVQSB0aGF0 IGRvZXMgbm90IHN1cHBvcnQgYm90aCBNVVNUIE5PVCB1c2UgU0lQUkVDPykNCj4+PjIuU1JTIE1V U1Qgc3VwcG9ydCBib3RoIChhbmQgYWxsb3cgU1JDIHRvIHN1cHBvcnQgYm90aCBzaW11bHRhbmVv dXNseT8NCj4+PkFuZA0KPj4+aG93IGRvIHlvdSBuZWdvdGlhdGlvbiB0aGF0ID8pDQo+Pj4zLlBy b3ZpZGUgcmVjb21tZW5kYXRpb25zIGFuZCBsZWF2ZSBhcyBxdWFsaXR5IG9mIGltcGxlbWVudGF0 aW9uDQo+Pj5kZWNpc2lvbg0KPj4+KGFuZCBsaXZlIHdpdGggaW50ZXJvcGVyYWJpbGl0eSBpc3N1 ZXM/KQ0KPj4+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+Pg0KPj4+RGlzY3Vzc2lv biBpbiByb29tIChmcm9tIG1pbnV0ZXM6DQo+Pj5odHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJj aGl2ZS93ZWIvc2lwcmVjL2N1cnJlbnQvbXNnMDM5MzQuaHRtbCkNCj4+Pi0gUGF1bCBLIC0gbm8g YnJhaW5lciwgU1JTIGlzIHRoZSBwb3dlcmZ1bCBib3ggLSB0aGF0IGlzIHRoZSBwbGFjZSB0bw0K Pj4+cHV0DQo+Pj5yZXF1aXJlbWVudHMgLSAyIGlzIHByZWZlcmFibGUgdG8gMSAtIDIgdnMuIDMs IEknbSBub3Qgc3VyZSwga2luZCBvZg0KPj4+aW5jbGluZWQgZm9yIDIgYnV0IG5vdCBzdXJlDQo+ Pj4tIENoYWlyOiBkZWZpbml0aXZlIGlzIGJlc3QgZm9yIGltcGxlbWVudGF0aW9uDQo+Pj4tIENo YXJsZXM6IG9wdGlvbiAzIGlzIG15IHN1Z2dlc3Rpb24gKGFzIHRoZSBkcmFmdCBpcyksIGJ1dCBj b3VsZCBsaXZlDQo+Pj53aXRoIG9wdGlvbiAyIC0gd291bGQgYXBwcmVjaWF0ZSBzb21lIGhlbHAg d2l0aCB0aGUgdGV4dCAtIG5lZWQgdG8gdGhpbmsNCj4+PmFib3V0IHVzZSBjYXNlcyAtIGlmIGEg VUEgaXMgY2FwYWJsZSBvZiBkZWFsaW5nIHdpdGggYm90aCwgaXQgY2FuDQo+Pj5zaW1wbGlmeQ0K Pj4+Zm9yIHRoZSBTUlMsIGJ1dCBkZXBlbmRzIG9uIGNhcGFiaWxpdGllcyBvZiB0aGUgU1JDIGFu ZCBTUlMgLSBpZiB3ZSBjYW4NCj4+PmRvDQo+Pj5iZXR0ZXIgdGhhdCBpcyBncmVhdA0KPj4+LSBD aGFpcjogbGV0J3MgaGF2ZSBtb3JlIGxpc3QgZGlzY3Vzc2lvbiBiZWNhdXNlIG1pc3NpbmcgcGVv cGxlIC0gYnV0IGluDQo+Pj5mYXZvdXIgb2YgZG9jdW1lbnRpbmcgb25lIGFuZCBnZW5lcmFsbHkg aW4gZmF2b3VyIG9mIGhhdmluZyB0aGUgc2VydmVyDQo+Pj5kbw0KPj4+dGhlIHdvcmsgLSB0ZW50 YXRpdmVseSB0aGluayBnb2luZyBpbiB0aGUgZGlyZWN0aW9uIG9mIG9wdGlvbiAyDQo+Pj4NCj4+ PlRob3VnaHRzPw0KPj4+DQo+Pj5DaGVlcnMsDQo+Pj5DaGFybGVzDQo+Pj4NCj4+Pl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj5zaXByZWMgbWFpbGlu ZyBsaXN0DQo+Pj5zaXByZWNAaWV0Zi5vcmcNCj4+Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vc2lwcmVjDQo+Pg0KPg0KDQo= From nobody Sat Jun 28 11:07:37 2014 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6886A1A0393 for ; Sat, 28 Jun 2014 11:07:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.635 X-Spam-Level: X-Spam-Status: No, score=-0.635 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_32=0.6, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5IfNI007gvqv for ; Sat, 28 Jun 2014 11:07:33 -0700 (PDT) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:211]) by ietfa.amsl.com (Postfix) with ESMTP id 480801A038F for ; Sat, 28 Jun 2014 11:07:31 -0700 (PDT) Received: from omta04.westchester.pa.mail.comcast.net ([76.96.62.35]) by QMTA11.westchester.pa.mail.comcast.net with comcast id Ku1b1o0010ldTLk5Bu7Wpd; Sat, 28 Jun 2014 18:07:30 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta04.westchester.pa.mail.comcast.net with comcast id Ku7W1o00M3ZTu2S01u7WmF; Sat, 28 Jun 2014 18:07:30 +0000 Message-ID: <53AF0462.4050600@alum.mit.edu> Date: Sat, 28 Jun 2014 14:07:30 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: siprec@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=EUC-KR Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1403978850; bh=IwgIqX3byR9eSl1peaWSwKmTu/IpsYdfwCO6DdwWbBA=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=VklP2i+JQy1PuQGMfWxUp8Pnsd4KqR3PgAvlL6eOg/Rcr1zmCBCtwD7Qg5ra2O4Vn XdHiaUwnz/zjpPDrr+dnHdLl0tiKJKBeyoHyRDjg6Wy/eR5uUOLNc+zrkBWObJJx/k MjAv8DmDzDbbMDIxxPt7HJztz+2yvGKHhUji61bAfBvFrQRgxOXoegfPppjT2g9eqL DjqEGqvDOoz8RX7yChFAto8bn82VumR71KkiOkJYA0nGYqsfmr/ClUtrs6T30vARW/ 569NnUuv+2NuDS/GMec/z0bZ43OIIxXIKanWrbWIx3pzJwNXhl/+N5ZMiCsUNUWwR5 7J22FUGGdujAg== Archived-At: http://mailarchive.ietf.org/arch/msg/siprec/4PyKUXORczZr0mRK2j7sGVb1AOI Subject: Re: [siprec] FIR vs. SIP INFO X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jun 2014 18:07:35 -0000 On 6/28/14 12:54 PM, Ram Mohan R (rmohanr) wrote: > Proposed text looks good to me. +1 > Ram > > -----Original Message----- > From: "Charles Eckel (eckelcu)" > Date: Saturday, 14 June 2014 10:21 am > To: Ram Mohan Ravindranath , "siprec@ietf.org" > > Subject: Re: [siprec] FIR vs. SIP INFO > >> Reviving a sleeping thread ¡¦ >> >> The sense of the room, as captured in the meeting minutes, was that we add >> a requirement on the SRS to support both methods. Continuing the >> discussion on the list resulted in only one addition comment, from Ram, in >> support of this proposal. >> With this in mind, I propose we append the following to section 8.1.7.1.1: >> >> "To make sure a common mechanism exists between the SRC and SRS, the SRS >> MUST support both mechanisms (FIR and SIP INFO), using FIR when negotiated >> successfully with the SRC, and using SIP INFO otherwise." >> >> Comments and other ideas welcome. >> >> Cheers, >> Charles >> >> On 3/20/14, 8:03 PM, "Ram Mohan R (rmohanr)" wrote: >> >>> I prefer option 2 as mandatory since SRS is the one that eventually looks >>> at the media being recorded(RTP) and is the best one to decide on whether >>> to generate a FIR or SIP INFO. However we may also allow a SRC to >>> generate a FIR/SIP INFO. So I prefer that we can keep MUST for option 2 >>> and MAY for option 1. >>> >>> I have a slightly different question on this - >>> Do we want SRS(or SRC) to always generate both FIR and SIP INFO ? There >>> may be cases where endpoint (UA) may support one or both of them. If a UA >>> supports both of them it may result in a case where UA may re-transmit >>> IDR >>> frame twice (one on receipt of FIR and other on on receipt of SIP INFO). >>> This is ok in principle but may lead to more network congestion due to >>> bursty traffic. Is this some thing we should worry about ? >>> >>> Perhaps if there is a way SRS/SRC can find what method the UA prefers >>> (FIR >>> or SIP INFO) it can only generate that. >>> >>> Ram >>> >>> >>> -----Original Message----- >>> From: "Charles Eckel (eckelcu)" >>> Date: Friday, 21 March 2014 2:34 am >>> To: "siprec@ietf.org" >>> Subject: [siprec] FIR vs. SIP INFO >>> >>>> To the best of my knowledge, this is the last open item in the protocol >>>> draft. Here is the info from the slide presented at IETF 89 in London: >>>> >>>> FIR and SIP INFO requirements in SRC and/or SRS >>>> ------------------------ >>>> Section 8.1.7.1.1 SIP INFO for FIR >>>> ¡§"XML Schema for Media Control©÷ [RFC5168 >>>> ] defines an Extensible Markup >>>> Language (XML) Schema for video fast update. Implementations are >>>> discouraged from using the method described except for backward >>>> compatibility purposes. Implementations SHOULD use FIR messages instead. >>>> >>>> NENA ICE-8 event feedback, do we need to say more? Options: >>>> 1.SRC MUST support both and provide interworking to what SRS supports >>>> (and >>>> an UA that does not support both MUST NOT use SIPREC?) >>>> 2.SRS MUST support both (and allow SRC to support both simultaneously? >>>> And >>>> how do you negotiation that ?) >>>> 3.Provide recommendations and leave as quality of implementation >>>> decision >>>> (and live with interoperability issues?) >>>> ----------------------------- >>>> >>>> Discussion in room (from minutes: >>>> http://www.ietf.org/mail-archive/web/siprec/current/msg03934.html) >>>> - Paul K - no brainer, SRS is the powerful box - that is the place to >>>> put >>>> requirements - 2 is preferable to 1 - 2 vs. 3, I'm not sure, kind of >>>> inclined for 2 but not sure >>>> - Chair: definitive is best for implementation >>>> - Charles: option 3 is my suggestion (as the draft is), but could live >>>> with option 2 - would appreciate some help with the text - need to think >>>> about use cases - if a UA is capable of dealing with both, it can >>>> simplify >>>> for the SRS, but depends on capabilities of the SRC and SRS - if we can >>>> do >>>> better that is great >>>> - Chair: let's have more list discussion because missing people - but in >>>> favour of documenting one and generally in favour of having the server >>>> do >>>> the work - tentatively think going in the direction of option 2 >>>> >>>> Thoughts? >>>> >>>> Cheers, >>>> Charles >>>> >>>> _______________________________________________ >>>> siprec mailing list >>>> siprec@ietf.org >>>> https://www.ietf.org/mailman/listinfo/siprec >>> >> > > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec >