From nobody Mon Aug 4 10:11:14 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 66EDB1A0067 for ; Mon, 4 Aug 2014 10:11:13 -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 C7CdwgkBBAmv for ; Mon, 4 Aug 2014 10:11:04 -0700 (PDT) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:228]) by ietfa.amsl.com (Postfix) with ESMTP id 861401A0066 for ; Mon, 4 Aug 2014 10:11:04 -0700 (PDT) Received: from omta10.westchester.pa.mail.comcast.net ([76.96.62.28]) by qmta15.westchester.pa.mail.comcast.net with comcast id afae1o0060cZkys5FhB4Ki; Mon, 04 Aug 2014 17:11:04 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta10.westchester.pa.mail.comcast.net with comcast id ahB31o00q3ZTu2S3WhB3nz; Mon, 04 Aug 2014 17:11:04 +0000 Message-ID: <53DFBEA7.2060503@alum.mit.edu> Date: Mon, 04 Aug 2014 13:11:03 -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: <20140804155854.25529.12420.idtracker@ietfa.amsl.com> In-Reply-To: <20140804155854.25529.12420.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20140804155854.25529.12420.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1407172264; bh=oJqdluBsKxLxWemPux5EKRdFEd9jHKl6uzium/YBrbg=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=FckmgxjGPcJeISi2AgWNDgKoU0uA8WpRfUOAye5PYKP0PhcTr+6HEbAhqh9lXmgI2 gJKqc6zwK+JIr8IlugeeFoHl/77bvZ/K2ZpyOoVeiPsLekyrjHVzIQ2AFZa4oOS7Zh yUIdG/wVvsQPAPegPOAQMXONGZoVpclbc2SIbIEMZdBqR/UvkiTE4j+PWHCj69zyLO FEGdnh3031mFWdj841aGdUxNJHJmBSl+ZhwpKPrNU+ZT1YxAPW+v//KvVI/rvlTtYg 97+wIEliVTlpDYz7zQ097pWnsDzgAs59kKyB8eW3eoJcB1MNzqK2JGcwLHlWtPpkIO CibUr24E2lWNQ== Archived-At: http://mailarchive.ietf.org/arch/msg/siprec/ow0I1GWZ2KOtJ1ATQu2w1mUZQsU Subject: [siprec] Fwd: New Version Notification for draft-kyzivat-siprec-conference-use-cases-02.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: Mon, 04 Aug 2014 17:11:13 -0000 This is just a refresh to keep it from expiring. Thanks, Paul -------- Original Message -------- Subject: New Version Notification for draft-kyzivat-siprec-conference-use-cases-02.txt Date: Mon, 04 Aug 2014 08:58:54 -0700 From: internet-drafts@ietf.org To: Michael Yan , Simon Pietro Romano , "Paul H. Kyzivat" , "Paul Kyzivat" , "Michael Yan" , "Simon Romano" A new version of I-D, draft-kyzivat-siprec-conference-use-cases-02.txt has been successfully submitted by Paul H. Kyzivat and posted to the IETF repository. Name: draft-kyzivat-siprec-conference-use-cases Revision: 02 Title: Multimedia Conference Recording Use Cases and Requirements Document date: 2014-08-04 Group: Individual Submission Pages: 10 URL: http://www.ietf.org/internet-drafts/draft-kyzivat-siprec-conference-use-cases-02.txt Status: https://datatracker.ietf.org/doc/draft-kyzivat-siprec-conference-use-cases/ Htmlized: http://tools.ietf.org/html/draft-kyzivat-siprec-conference-use-cases-02 Diff: http://www.ietf.org/rfcdiff?url2=draft-kyzivat-siprec-conference-use-cases-02 Abstract: The current work of SIPREC will soon finish. As conferences are the key requirement for some environments, it is worth to explore several extensions and additional functionality to support multimedia conference recording. SIPREC is not sufficient to record all the conference sessions via certain interactive media channels, like multi-user chat or screen sharing. This draft tries to show the use cases for multimedia conference recording and the requirements for how to work well under SIPREC mechanism. The requirements ask for extensions to SIP that will manage delivery of RTP media sessions, including content media defined by [RFC4796] , and MSRP media sessions to a recording device. The recorded media sessions are all SIP-based. 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 From nobody Wed Aug 6 13:37:45 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 5B2FE1A013B for ; Wed, 6 Aug 2014 13:37:44 -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, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001] 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 XQQiwl2R6pCM for ; Wed, 6 Aug 2014 13:37:42 -0700 (PDT) Received: from mx11.unify.com (mx11.unify.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id C10751A0033 for ; Wed, 6 Aug 2014 13:37:42 -0700 (PDT) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by mx11.unify.com (Server) with ESMTP id B90831EB8511 for ; Wed, 6 Aug 2014 22:37:41 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.120]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.03.0195.001; Wed, 6 Aug 2014 22:37:41 +0200 From: "Hutton, Andrew" To: "siprec@ietf.org" Thread-Topic: IETF90 Minutes. Thread-Index: Ac+xtkTSl2SS3f8+QNKOx8cjDFco9g== Date: Wed, 6 Aug 2014 20:37:40 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF17E40CAC@MCHP04MSX.global-ad.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: multipart/alternative; boundary="_000_9F33F40F6F2CD847824537F3C4E37DDF17E40CACMCHP04MSXglobal_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/siprec/SqkL7gGpgNVO0ItSxi9PVdyQSg4 Subject: [siprec] IETF90 Minutes. 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: Wed, 06 Aug 2014 20:37:44 -0000 --_000_9F33F40F6F2CD847824537F3C4E37DDF17E40CACMCHP04MSXglobal_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, Due to vacation I have not had time to sort the minutes our properly but ha= ve posted the raw notes will check the minutes properly next week. See http://www.ietf.org/proceedings/90/minutes/minutes-90-siprec. Regards Andy --_000_9F33F40F6F2CD847824537F3C4E37DDF17E40CACMCHP04MSXglobal_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi All,
 
Due to vacation I have not had time to sort the minutes our properly b= ut have posted the raw notes will check the minutes properly next week.
 
 
Regards
Andy
 
 --_000_9F33F40F6F2CD847824537F3C4E37DDF17E40CACMCHP04MSXglobal_-- From nobody Thu Aug 7 10:27:01 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 56B821A0005; Thu, 7 Aug 2014 10:26:51 -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 85o5TbL3nkoe; Thu, 7 Aug 2014 10:26:48 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B51D1B2EB5; Thu, 7 Aug 2014 10:26:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140807172634.13183.94089.idtracker@ietfa.amsl.com> Date: Thu, 07 Aug 2014 10:26:34 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/siprec/cHQ6zpXJE9fi6XvzavBGOHpDeu4 Cc: siprec@ietf.org Subject: [siprec] I-D Action: draft-ietf-siprec-metadata-16.txt 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: Thu, 07 Aug 2014 17:26:51 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP Recording Working Group of the IETF. Title : Session Initiation Protocol (SIP) Recording Metadata Authors : Ram Mohan Ravindranath Parthasarathi Ravindran Paul Kyzivat Filename : draft-ietf-siprec-metadata-16.txt Pages : 29 Date : 2014-08-07 Abstract: Session recording is a critical requirement in many communications environments such as call centers and financial trading. In some of these environments, all calls must be recorded for regulatory, compliance, and consumer protection reasons. Recording of a session is typically performed by sending a copy of a media stream to a recording device. This document describes the metadata model as viewed by Session Recording Server(SRS) and the Recording metadata format. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-siprec-metadata/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-siprec-metadata-16 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-siprec-metadata-16 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Aug 7 10:30:59 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 46B341A0012 for ; Thu, 7 Aug 2014 10:30:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, 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 8ZuQWBTibqsU for ; Thu, 7 Aug 2014 10:30:54 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C3241A007A for ; Thu, 7 Aug 2014 10:30:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2134; q=dns/txt; s=iport; t=1407432623; x=1408642223; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=ysBKAoXfcGjqLWcYFCaPVBeAjh6PJcZTEOTsAhfCFcE=; b=WMBb70FHWtjaTos+9zoV2RxMXOhABxKztMSV3vyi3IGm4f5JUpfo7CNk 6NI9cRt4DrSwdQBq3RR0Y2Z3ffeKHQGNywLimWxaxN4eAz8fQlRwBuOYj f1cxudl0tVvb6W4bKzrEqQZJfktSSvUMnh3C4XfgIkw6lwgAwE7iWIhCe Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjQFAHi241OtJA2I/2dsb2JhbABagw1SUwQEzEgKhnVTAYEVFneEAwEBAQQBAQE3NBcEAgEIEQMBAh8QJwsdCAIEEwmIOQgFxBQXj1MGhEUFlTOGaIFUkxyDV2yBRg X-IronPort-AV: E=Sophos;i="5.01,819,1400025600"; d="scan'208";a="67374586" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-2.cisco.com with ESMTP; 07 Aug 2014 17:30:22 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s77HUMJG031769 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 7 Aug 2014 17:30:22 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.232]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0123.003; Thu, 7 Aug 2014 12:30:22 -0500 From: "Ram Mohan R (rmohanr)" To: "siprec@ietf.org" Thread-Topic: [siprec] I-D Action: draft-ietf-siprec-metadata-16.txt Thread-Index: AQHPsmUNcLjWR7yC3kOJCYUB6rHqtZvGFmUA Date: Thu, 7 Aug 2014 17:30:21 +0000 Message-ID: References: <20140807172634.13183.94089.idtracker@ietfa.amsl.com> In-Reply-To: <20140807172634.13183.94089.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-originating-ip: [10.65.40.205] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/siprec/IWN_dSUufD6bwMk0SRkzCXAUBb0 Subject: Re: [siprec] I-D Action: draft-ietf-siprec-metadata-16.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, 07 Aug 2014 17:30:56 -0000 Just a refresh to keep the draft from expiring. Ram -----Original Message----- From: "internet-drafts@ietf.org" Date: Thursday, 7 August 2014 10:56 pm To: "i-d-announce@ietf.org" Cc: "siprec@ietf.org" Subject: [siprec] I-D Action: draft-ietf-siprec-metadata-16.txt > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > This draft is a work item of the SIP Recording Working Group of the IETF. > > Title : Session Initiation Protocol (SIP) Recording >Metadata > Authors : Ram Mohan Ravindranath > Parthasarathi Ravindran > Paul Kyzivat > Filename : draft-ietf-siprec-metadata-16.txt > Pages : 29 > Date : 2014-08-07 > >Abstract: > Session recording is a critical requirement in many communications > environments such as call centers and financial trading. In some of > these environments, all calls must be recorded for regulatory, > compliance, and consumer protection reasons. Recording of a session > is typically performed by sending a copy of a media stream to a > recording device. This document describes the metadata model as > viewed by Session Recording Server(SRS) and the Recording metadata > format. > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-siprec-metadata/ > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-ietf-siprec-metadata-16 > >A diff from the previous version is available at: >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-siprec-metadata-16 > > >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. > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >siprec mailing list >siprec@ietf.org >https://www.ietf.org/mailman/listinfo/siprec From nobody Tue Aug 12 14:43:31 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 F22AE1A09CE for ; Tue, 12 Aug 2014 14:43:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.168 X-Spam-Level: X-Spam-Status: No, score=-15.168 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, 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 ieqUd3m6CFmH for ; Tue, 12 Aug 2014 14:43:28 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB3401A0776 for ; Tue, 12 Aug 2014 14:43:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13099; q=dns/txt; s=iport; t=1407879807; x=1409089407; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=Gxj7KHByrISG98dA0QpzUQ63wjx3Bbx3kog0ZaedUB4=; b=eSOgtj+T51nbVoa7ucukKv0i4FuTuMrKwQGf+9qOYP2Z9GyAHL2ADa/c 1viJAkxf6UdvD8zdhKcvYgyTnK+chQNbDfvPZ2p6Q1wpd71DhRxVBaDiJ REWpclZqgnGP7SzuZyaeErykHtWUMaZtE/XKAFk7MeSVNduISTa+5AGLo w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhcFAEGJ6lOtJV2Q/2dsb2JhbABagkdGgSkE1HcBgRYWd4QDAQEBBIEJAgEIEQMBAigHIREUCQgCBAESiC4DEb9hDYVDF40fghwYBoRGBZEdhl+CL4IOjkuGM4NcbAGBRw X-IronPort-AV: E=Sophos; i="5.01,852,1400025600"; d="scan'208,217"; a="68699437" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-2.cisco.com with ESMTP; 12 Aug 2014 21:43:25 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s7CLhOSp015176 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 12 Aug 2014 21:43:25 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.199]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0195.001; Tue, 12 Aug 2014 16:43:24 -0500 From: "Charles Eckel (eckelcu)" To: Alan Johnston , "siprec@ietf.org" Thread-Topic: [siprec] Normative Statements in draft-ietf-siprec-protocol-13 Thread-Index: AQHPqBfa9thZXiMc7UmPSC7txuSeQJvNeykA Date: Tue, 12 Aug 2014 21:43:24 +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.154.176.22] Content-Type: multipart/alternative; boundary="_000_D00FCCE731334eckelcuciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/siprec/QediSIweVhSFzzCko0sd4yCNXFs Subject: Re: [siprec] Normative Statements in draft-ietf-siprec-protocol-13 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, 12 Aug 2014 21:43:30 -0000 --_000_D00FCCE731334eckelcuciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Alan, Thanks for the valuable comments. Please see my proposed resolution for eac= h inline. From: Alan Johnston > Date: Friday, July 25, 2014 at 7:50 AM To: "siprec@ietf.org" > Subject: [siprec] Normative Statements in draft-ietf-siprec-protocol-13 Here's a few comments on some normative statements in draft-ietf-siprec-pro= tocol-13. "In order to communicate most effectively, the Session Recording Client (SR= C), the Session Recording Server (SRS), and any Recording aware User Agents= (UAs) SHOULD utilize the mechanisms provided by RTP in a well-defined and = predicable manner." I question whether this statement should have normative language, since it = isn't testable at all. I agree. Let=92s change to =93should=94. "Using the FIR command to recover from errors is explicitly disallowed, and= instead the PLI message SHOULD be used." The use of "disallowed" seems like a MUST NOT, but then PLI is a SHOULD whi= ch is confusing. I'd suggest using normative language instead of disallowe= d. This was taken from RFC 5104, which reads as follows, "Using the FIR comman= d to recover from errors is explicitly disallowed, and instead the PLI mess= age defined in AVPF [RFC4585] should be used. The PLI message reports lost= pictures and has been included in AVPF for precisely that purpose.=94 Section 8.1.7.2 of the SIP protocol drafts currently reads as follows, "Pic= ture Loss Indication (PLI), as defined in [RFC4585], informs the encoder of= the loss of an undefined amount of coded video data belonging to one or mo= re pictures. Using the FIR command to recover from errors is explicitly di= sallowed, and instead the PLI message SHOULD be used. FIR SHOULD be used o= nly in situations where not sending a decoder refresh point would render th= e video unusable for the users.=94 How about we change to, "Picture Loss Indication (PLI), as defined in [RFC4= 585], informs the encoder of the loss of an undefined amount of coded video= data belonging to one or more pictures. [RFC4585] recommends using PLI in= stead of FIR to recover from errors. FIR is appropriate only in situations = where not sending a decoder refresh point would render the video unusable f= or the users.=94 There are a bunch of normative statements that are repeated twice in differ= ent sections. For example: "If packet loss occurs from the UA to the SRC, the SRC SHOULD detect and at= tempt to recover from the loss." This statement appears in 8.2.2 and 8.2.3 for mixer and endpoint scenarios.= There are similar things in 8.3.1 and 8.3.2. Do we really want to repea= t this text? If not, perhaps we could consolidate these two sections into = three: - Section with normative statements that apply to both mixing and endpoint - Section with normative for mixing only - Section with normative for endpoint only Or, if we do want to keep the existing structure, maybe the normative state= ments could be prefixed with "For RTP mixing..." or "For RTP endpoint..." s= o each normative statement is unique. Section 8.2 deals with 4 types of RTP entities: 1. Forwarding translator 2. Transcoding translator 3. Mixer 4. Endpoint There is a subsection for each, and as you noted, there is normative langua= ge regarding packet loss within each subsection. Normative language exists = in each subsection. Each subsection is structured similarly, and as you not= ed, there is duplicated of normative language within each. I thought this h= elped with readability from the perspective of someone implementing the spe= c, but there are tradeoffs. We could pull packet loss into its own subsecti= on that deals with all 4 types of RTP entities. This might read as follows: "Section 8.x. Packet Loss If packet loss occurs from the UA to the SRC, the SRC, if acting as an RTP= mixer or RTP endpoint, SHOULD detect and attempt to recover from the loss.= If acting as an RTP translator (either forwarding or transcoding), the SRC= does detect or attempt to recover from the loss. It simply forwards the as= sociated RTP and RTCP packets. In such cases, as well as if packet loss occ= urs from the SRC to the SRS, the SRS SHOULD detect and attempt to recover f= rom the loss.=94 Note that this still leaves other normative language in the individual subs= ection. Is this okay/better? Something similar could be done for section 8.3, which describes different = RTP session usages: 1. SEC using multiple m-lines 2. SRC using mixing I made a couple attempts at this prior to sending this e-mail, but I was no= t happy with the end results. I=92m inclined to leave as is, but am open to= it being reworked as well. Cheers, Charles - Alan - --_000_D00FCCE731334eckelcuciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <67525DB74955AA4BB7C8A7C701521BFB@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi Alan,

Thanks for the valuable comments. Please see my proposed resolution fo= r each inline.

From: Alan Johnston <alan.b.johnston@gmail.com>
Date: Friday, July 25, 2014 at 7:50= AM
To: "siprec@ietf.org" <= siprec@ietf.org>
Subject: [siprec] Normative Stateme= nts in draft-ietf-siprec-protocol-13

Here's a few comments on some normative statements in draf= t-ietf-siprec-protocol-13.

"In order to communicate most effectively, the Session Recording = Client (SRC), the Session Recording Server (SRS), and any Recording aware U= ser Agents (UAs) SHOULD utilize the mechanisms provided by RTP in a well-de= fined and predicable manner."

I question whether this statement should have normative language, sinc= e it isn't testable at all.

I agree. Let=92s change to =93should=94.


"Using the FIR command to recover from errors is explicitly disal= lowed, and instead the PLI message SHOULD be used."

The use of "disallowed" seems like a MUST NOT, but then PLI = is a SHOULD which is confusing.  I'd suggest using normative language = instead of disallowed.

This was taken from RFC 5104, which reads as follows, "Using the = FIR command to recover from errors is explicitly disallowed, and instead th= e PLI message defined in AVPF [RFC4585] should be used.  The PLI messa= ge reports lost pictures and has been included in AVPF for precisely that purpose.=94

Section 8.1.7.2 of the SIP protocol drafts currently reads as follows,= "Picture Loss Indication (PLI), as defined in [RFC4585], informs the = encoder of the loss of an undefined amount of coded video data belonging to= one or more pictures.  Using the FIR command to recover from errors is explicitly disallowed, and instead the P= LI message SHOULD be used.  FIR SHOULD be used only in situations wher= e not sending a decoder refresh point would render the video unusable for t= he users.=94

How about we change to, "Picture Loss Indication (PLI), as define= d in [RFC4585], informs the encoder of the loss of an undefined amount of c= oded video data belonging to one or more pictures.  [RFC4585] recommen= ds using PLI instead of FIR to recover from errors. FIR is appropriate only in situations where not sending a decoder = refresh point would render the video unusable for the users.=94


There are a bunch of normative statements that are repeated twice in d= ifferent sections.  For example:

"If packet loss occurs from the UA to the SRC, the SRC SHOULD det= ect and attempt to recover from the loss." 

This statement appears in 8.2.2 and 8.2.3 for mixer and endpoint scena= rios.  There are similar things in 8.3.1 and 8.3.2.   Do we reall= y want to repeat this text?  If not, perhaps we could consolidate thes= e two sections into three:

- Section with normative statements that apply to both mixing and endp= oint
- Section with normative for mixing only
- Section with normative for endpoint only

Or, if we do want to keep the existing structure, maybe the normative = statements could be prefixed with "For RTP mixing..." or "Fo= r RTP endpoint..." so each normative statement is unique.

Section 8.2 deals with 4 types of RTP entities:
  1. Forwarding translator
  2. Transcoding translator
  3. Mixer = ;
  4. Endpoint
There is a subsection for each, and as you noted, there is normative l= anguage regarding packet loss within each subsection. Normative language ex= ists in each subsection. Each subsection is structured similarly, and as yo= u noted, there is duplicated of normative language within each. I thought this helped with readability fro= m the perspective of someone implementing the spec, but there are tradeoffs= . We could pull packet loss into its own subsection that deals with all 4 t= ypes of RTP entities. This might read as follows:

"Section 8.x. Packet Loss

If packet loss occurs from the UA to the SRC, the SRC, if acting as an=  RTP mixer or RTP endpoint, SHOULD detect and attempt to recover from= the loss. If acting as an RTP translator (either forwarding or transcoding= ), the SRC does detect or attempt to recover from the loss. It simply forwards the associated RTP and RTCP pack= ets. In such cases, as well as if packet loss occurs from the SRC to the SR= S, the SRS SHOULD detect and attempt to recover from the loss.=94

Note that this still leaves other normative language in the individual= subsection. Is this okay/better?
Something similar could be done for section 8.3, which describes diffe= rent RTP session usages:
  1. SEC using multiple m-lines
  2. SRC using mixing
I made a couple attempts at this prior to sending this e-mail, but I w= as not happy with the end results. I=92m inclined to leave as is, but am op= en to it being reworked as well.

Cheers,
Charles


- Alan -



 --_000_D00FCCE731334eckelcuciscocom_-- From nobody Fri Aug 15 06:33:31 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 B0E8A1A0ABF for ; Fri, 15 Aug 2014 06:33:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.668] 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 Nw0ekNh2H5DK for ; Fri, 15 Aug 2014 06:33:26 -0700 (PDT) Received: from mx12.unify.com (mx12.unify.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id BAD161A00B5 for ; Fri, 15 Aug 2014 06:33:23 -0700 (PDT) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by mx12.unify.com (Server) with ESMTP id 5E67223F0497; Fri, 15 Aug 2014 15:33:22 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.120]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.03.0195.001; Fri, 15 Aug 2014 15:33:21 +0200 From: "Hutton, Andrew" To: Alan Johnston Thread-Topic: [siprec] Normative Statements in draft-ietf-siprec-protocol-13 Thread-Index: AQHPqBfa9thZXiMc7UmPSC7txuSeQJvNeykAgARNVtA= Date: Fri, 15 Aug 2014 13:33:21 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF17E4A311@MCHP04MSX.global-ad.net> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: multipart/alternative; boundary="_000_9F33F40F6F2CD847824537F3C4E37DDF17E4A311MCHP04MSXglobal_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/siprec/RoDjKdJY0jnsr66oS-Qx1BmIbYo Cc: "siprec@ietf.org" Subject: Re: [siprec] Normative Statements in draft-ietf-siprec-protocol-13 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: Fri, 15 Aug 2014 13:33:29 -0000 --_000_9F33F40F6F2CD847824537F3C4E37DDF17E4A311MCHP04MSXglobal_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Alan, Could you let us know if you are happy with the changes Charles suggests. We would like to get this draft submitted to the IESG. Regards Andy From: siprec [mailto:siprec-bounces@ietf.org] On Behalf Of Charles Eckel (e= ckelcu) Sent: 12 August 2014 22:43 To: Alan Johnston; siprec@ietf.org Subject: Re: [siprec] Normative Statements in draft-ietf-siprec-protocol-13 Hi Alan, Thanks for the valuable comments. Please see my proposed resolution for eac= h inline. From: Alan Johnston > Date: Friday, July 25, 2014 at 7:50 AM To: "siprec@ietf.org" > Subject: [siprec] Normative Statements in draft-ietf-siprec-protocol-13 Here's a few comments on some normative statements in draft-ietf-siprec-pro= tocol-13. "In order to communicate most effectively, the Session Recording Client (SR= C), the Session Recording Server (SRS), and any Recording aware User Agents= (UAs) SHOULD utilize the mechanisms provided by RTP in a well-defined and = predicable manner." I question whether this statement should have normative language, since it = isn't testable at all. I agree. Let's change to "should". "Using the FIR command to recover from errors is explicitly disallowed, and= instead the PLI message SHOULD be used." The use of "disallowed" seems like a MUST NOT, but then PLI is a SHOULD whi= ch is confusing. I'd suggest using normative language instead of disallowe= d. This was taken from RFC 5104, which reads as follows, "Using the FIR comman= d to recover from errors is explicitly disallowed, and instead the PLI mess= age defined in AVPF [RFC4585] should be used. The PLI message reports lost= pictures and has been included in AVPF for precisely that purpose." Section 8.1.7.2 of the SIP protocol drafts currently reads as follows, "Pic= ture Loss Indication (PLI), as defined in [RFC4585], informs the encoder of= the loss of an undefined amount of coded video data belonging to one or mo= re pictures. Using the FIR command to recover from errors is explicitly di= sallowed, and instead the PLI message SHOULD be used. FIR SHOULD be used o= nly in situations where not sending a decoder refresh point would render th= e video unusable for the users." How about we change to, "Picture Loss Indication (PLI), as defined in [RFC4= 585], informs the encoder of the loss of an undefined amount of coded video= data belonging to one or more pictures. [RFC4585] recommends using PLI in= stead of FIR to recover from errors. FIR is appropriate only in situations = where not sending a decoder refresh point would render the video unusable f= or the users." There are a bunch of normative statements that are repeated twice in differ= ent sections. For example: "If packet loss occurs from the UA to the SRC, the SRC SHOULD detect and at= tempt to recover from the loss." This statement appears in 8.2.2 and 8.2.3 for mixer and endpoint scenarios.= There are similar things in 8.3.1 and 8.3.2. Do we really want to repea= t this text? If not, perhaps we could consolidate these two sections into = three: - Section with normative statements that apply to both mixing and endpoint - Section with normative for mixing only - Section with normative for endpoint only Or, if we do want to keep the existing structure, maybe the normative state= ments could be prefixed with "For RTP mixing..." or "For RTP endpoint..." s= o each normative statement is unique. Section 8.2 deals with 4 types of RTP entities: 1. Forwarding translator 2. Transcoding translator 3. Mixer 4. Endpoint There is a subsection for each, and as you noted, there is normative langua= ge regarding packet loss within each subsection. Normative language exists = in each subsection. Each subsection is structured similarly, and as you not= ed, there is duplicated of normative language within each. I thought this h= elped with readability from the perspective of someone implementing the spe= c, but there are tradeoffs. We could pull packet loss into its own subsecti= on that deals with all 4 types of RTP entities. This might read as follows: "Section 8.x. Packet Loss If packet loss occurs from the UA to the SRC, the SRC, if acting as an RTP= mixer or RTP endpoint, SHOULD detect and attempt to recover from the loss.= If acting as an RTP translator (either forwarding or transcoding), the SRC= does detect or attempt to recover from the loss. It simply forwards the as= sociated RTP and RTCP packets. In such cases, as well as if packet loss occ= urs from the SRC to the SRS, the SRS SHOULD detect and attempt to recover f= rom the loss." Note that this still leaves other normative language in the individual subs= ection. Is this okay/better? Something similar could be done for section 8.3, which describes different = RTP session usages: 1. SEC using multiple m-lines 2. SRC using mixing I made a couple attempts at this prior to sending this e-mail, but I was no= t happy with the end results. I'm inclined to leave as is, but am open to i= t being reworked as well. Cheers, Charles - Alan - --_000_9F33F40F6F2CD847824537F3C4E37DDF17E4A311MCHP04MSXglobal_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Alan,

 <= /p>

Could you let us know if = you are happy with the changes Charles suggests.

 <= /p>

We would like to get this= draft submitted to the IESG.

 <= /p>

Regards=

Andy

 <= /p>

 <= /p>

 <= /p>

From: siprec [= mailto:siprec-bounces@ietf.org] On Behalf Of Charles Eckel (eckelcu)
Sent: 12 August 2014 22:43
To: Alan Johnston; siprec@ietf.org
Subject: Re: [siprec] Normative Statements in draft-ietf-siprec-prot= ocol-13

 

Hi Alan,<= /p>

 

Thanks for the valuable com= ments. Please see my proposed resolution for each inline.=

 

From: Alan Johnston <alan.b.johnston@gmail.com>
Date: Friday, July 25, 2014 at 7:50 AM
To: "siprec@ietf.org&quo= t; <siprec@ietf.org>
Subject: [siprec] Normative Statements in draft-ietf-siprec-protocol= -13

 

Here's a few comments on so= me normative statements in draft-ietf-siprec-protocol-13.

 

"In order to communica= te most effectively, the Session Recording Client (SRC), the Session Record= ing Server (SRS), and any Recording aware User Agents (UAs) SHOULD utilize the mechanisms provided by RTP in a well-defined and predicable ma= nner."

 

I question whether this sta= tement should have normative language, since it isn't testable at all.=

 

I agree. Let’s change= to “should”.

 

 

"Using the FIR command= to recover from errors is explicitly disallowed, and instead the PLI messa= ge SHOULD be used."

 

The use of "disallowed= " seems like a MUST NOT, but then PLI is a SHOULD which is confusing. =  I'd suggest using normative language instead of disallowed.

 

This was taken from RFC 510= 4, which reads as follows, "Using the FIR command to recover from erro= rs is explicitly disallowed, and instead the PLI message defined in AVPF [RFC4585] should be used.  The PLI message reports lost pictu= res and has been included in AVPF for precisely that purpose.”

 

Section 8.1.7.2 of the SIP = protocol drafts currently reads as follows, "Picture Loss Indication (= PLI), as defined in [RFC4585], informs the encoder of the loss of an undefined amount of coded video data belonging to one or more pictur= es.  Using the FIR command to recover from errors is explicitly disall= owed, and instead the PLI message SHOULD be used.  FIR SHOULD be used = only in situations where not sending a decoder refresh point would render the video unusable for the users.”

 

How about we change to, &qu= ot;Picture Loss Indication (PLI), as defined in [RFC4585], informs the enco= der of the loss of an undefined amount of coded video data belonging to one or more pictures.  [RFC4585] recommends using PLI instead of F= IR to recover from errors. FIR is appropriate only in situations where not = sending a decoder refresh point would render the video unusable for the use= rs.”

 

 

There are a bunch of normat= ive statements that are repeated twice in different sections.  For exa= mple:

 

"If packet loss occurs= from the UA to the SRC, the SRC SHOULD detect and attempt to recover from = the loss." 

 

This statement appears in 8= .2.2 and 8.2.3 for mixer and endpoint scenarios.  There are similar th= ings in 8.3.1 and 8.3.2.   Do we really want to repeat this text?  If not, perhaps we could consolidate these two sections into three:<= o:p>

 

- Section with normative st= atements that apply to both mixing and endpoint

- Section with normative fo= r mixing only

- Section with normative fo= r endpoint only

 

Or, if we do want to keep t= he existing structure, maybe the normative statements could be prefixed wit= h "For RTP mixing..." or "For RTP endpoint..." so each = normative statement is unique.

 

Section 8.2 deals with 4 ty= pes of RTP entities:

  1. Forwarding translator
  2. Transcoding translator
  3. Mixer 
  4. Endpoint

There is a subsection for e= ach, and as you noted, there is normative language regarding packet loss wi= thin each subsection. Normative language exists in each subsection. Each subsection is structured similarly, and as you noted, the= re is duplicated of normative language within each. I thought this helped w= ith readability from the perspective of someone implementing the spec, but = there are tradeoffs. We could pull packet loss into its own subsection that deals with all 4 types of RTP ent= ities. This might read as follows:

 

"Section 8.x. Packet L= oss

 

If packet loss occurs from = the UA to the SRC, the SRC, if acting as an  RTP mixer or RTP endpoint= , SHOULD detect and attempt to recover from the loss. If acting as an RTP translator (either forwarding or transcoding), the SRC does dete= ct or attempt to recover from the loss. It simply forwards the associated R= TP and RTCP packets. In such cases, as well as if packet loss occurs from t= he SRC to the SRS, the SRS SHOULD detect and attempt to recover from the loss.”

 

Note that this still leaves= other normative language in the individual subsection. Is this okay/better= ?

Something similar could be = done for section 8.3, which describes different RTP session usages:

  1. SEC using multiple m-lines
  2. SRC using mixing

I made a couple attempts at= this prior to sending this e-mail, but I was not happy with the end result= s. I’m inclined to leave as is, but am open to it being reworked as well.

 

Cheers,

Charles

 

 

- Alan -<= /p>

 

 

 

--_000_9F33F40F6F2CD847824537F3C4E37DDF17E4A311MCHP04MSXglobal_-- From nobody Fri Aug 15 07:30:13 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 9D85C1A8A6C for ; Fri, 15 Aug 2014 07:30:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 NwSDfGYDh-T8 for ; Fri, 15 Aug 2014 07:30:09 -0700 (PDT) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5382F1A8A6A for ; Fri, 15 Aug 2014 07:30:09 -0700 (PDT) Received: by mail-wi0-f180.google.com with SMTP id n3so897763wiv.7 for ; Fri, 15 Aug 2014 07:30:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=YpslF9FLtPPspUvgIyQpkTKqm4f9+6mmrJAgEsaROpM=; b=pTt9qfuY3vi0fegwCJY9YVgWPLz3Pl8K6gRCRR5Ia3X6A+wKMvhnTtdkSwM2MjS+jK WCVjJj8x0WeTrn8qyIHIOXDaAYa8RZJB3kbJctG4qlWD+EBWNdezuHN9LAv34Hurs3R/ JRzvmyeifcqhfanAK2ZZjamFGIEeJGiZSH6bVQWQM7MfmAxsiJE6TTWC/HnkEGL5bZVF ah+y7HZhg+OpQm+zQMJL4P54sxuJkGL01KZY4khIhLGzWV7zslZv0e4AxFnLecbDZCF9 z7+CZLAo85Kr+XM0nBQZw9Jf65dWfPHVgSoCnTR/g972IgJpLB+ceh8C51FntRyoPP9Q itQQ== MIME-Version: 1.0 X-Received: by 10.180.95.66 with SMTP id di2mr21269501wib.60.1408113007733; Fri, 15 Aug 2014 07:30:07 -0700 (PDT) Received: by 10.216.108.135 with HTTP; Fri, 15 Aug 2014 07:30:07 -0700 (PDT) In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF17E4A311@MCHP04MSX.global-ad.net> References: <9F33F40F6F2CD847824537F3C4E37DDF17E4A311@MCHP04MSX.global-ad.net> Date: Fri, 15 Aug 2014 09:30:07 -0500 Message-ID: From: Alan Johnston To: "Hutton, Andrew" Content-Type: multipart/alternative; boundary=f46d04182524a134260500abdbf2 Archived-At: http://mailarchive.ietf.org/arch/msg/siprec/ydirwBrB-iqNoZ-KbYBoOb4_i1s Cc: "siprec@ietf.org" Subject: Re: [siprec] Normative Statements in draft-ietf-siprec-protocol-13 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: Fri, 15 Aug 2014 14:30:11 -0000 --f46d04182524a134260500abdbf2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Charles, Thanks for the reply. I'm fine with your suggestions. - Alan - On Fri, Aug 15, 2014 at 8:33 AM, Hutton, Andrew wrote: > Alan, > > > > Could you let us know if you are happy with the changes Charles suggests. > > > > We would like to get this draft submitted to the IESG. > > > > Regards > > Andy > > > > > > > > *From:* siprec [mailto:siprec-bounces@ietf.org] *On Behalf Of *Charles > Eckel (eckelcu) > *Sent:* 12 August 2014 22:43 > *To:* Alan Johnston; siprec@ietf.org > *Subject:* Re: [siprec] Normative Statements in > draft-ietf-siprec-protocol-13 > > > > Hi Alan, > > > > Thanks for the valuable comments. Please see my proposed resolution for > each inline. > > > > *From: *Alan Johnston > *Date: *Friday, July 25, 2014 at 7:50 AM > *To: *"siprec@ietf.org" > *Subject: *[siprec] Normative Statements in draft-ietf-siprec-protocol-13 > > > > Here's a few comments on some normative statements in > draft-ietf-siprec-protocol-13. > > > > "In order to communicate most effectively, the Session Recording Client > (SRC), the Session Recording Server (SRS), and any Recording aware User > Agents (UAs) SHOULD utilize the mechanisms provided by RTP in a > well-defined and predicable manner." > > > > I question whether this statement should have normative language, since i= t > isn't testable at all. > > > > I agree. Let=E2=80=99s change to =E2=80=9Cshould=E2=80=9D. > > > > > > "Using the FIR command to recover from errors is explicitly disallowed, > and instead the PLI message SHOULD be used." > > > > The use of "disallowed" seems like a MUST NOT, but then PLI is a SHOULD > which is confusing. I'd suggest using normative language instead of > disallowed. > > > > This was taken from RFC 5104, which reads as follows, "Using the FIR > command to recover from errors is explicitly disallowed, and instead the > PLI message defined in AVPF [RFC4585] should be used. The PLI message > reports lost pictures and has been included in AVPF for precisely that > purpose.=E2=80=9D > > > > Section 8.1.7.2 of the SIP protocol drafts currently reads as follows, > "Picture Loss Indication (PLI), as defined in [RFC4585], informs the > encoder of the loss of an undefined amount of coded video data belonging = to > one or more pictures. Using the FIR command to recover from errors is > explicitly disallowed, and instead the PLI message SHOULD be used. FIR > SHOULD be used only in situations where not sending a decoder refresh poi= nt > would render the video unusable for the users.=E2=80=9D > > > > How about we change to, "Picture Loss Indication (PLI), as defined in > [RFC4585], informs the encoder of the loss of an undefined amount of code= d > video data belonging to one or more pictures. [RFC4585] recommends using > PLI instead of FIR to recover from errors. FIR is appropriate only in > situations where not sending a decoder refresh point would render the vid= eo > unusable for the users.=E2=80=9D > > > > > > There are a bunch of normative statements that are repeated twice in > different sections. For example: > > > > "If packet loss occurs from the UA to the SRC, the SRC SHOULD detect and > attempt to recover from the loss." > > > > This statement appears in 8.2.2 and 8.2.3 for mixer and endpoint > scenarios. There are similar things in 8.3.1 and 8.3.2. Do we really > want to repeat this text? If not, perhaps we could consolidate these two > sections into three: > > > > - Section with normative statements that apply to both mixing and endpoin= t > > - Section with normative for mixing only > > - Section with normative for endpoint only > > > > Or, if we do want to keep the existing structure, maybe the normative > statements could be prefixed with "For RTP mixing..." or "For RTP > endpoint..." so each normative statement is unique. > > > > Section 8.2 deals with 4 types of RTP entities: > > 1. Forwarding translator > 2. Transcoding translator > 3. Mixer > 4. Endpoint > > There is a subsection for each, and as you noted, there is normative > language regarding packet loss within each subsection. Normative language > exists in each subsection. Each subsection is structured similarly, and a= s > you noted, there is duplicated of normative language within each. I thoug= ht > this helped with readability from the perspective of someone implementing > the spec, but there are tradeoffs. We could pull packet loss into its own > subsection that deals with all 4 types of RTP entities. This might read a= s > follows: > > > > "Section 8.x. Packet Loss > > > > If packet loss occurs from the UA to the SRC, the SRC, if acting as an > RTP mixer or RTP endpoint, SHOULD detect and attempt to recover from the > loss. If acting as an RTP translator (either forwarding or transcoding), > the SRC does detect or attempt to recover from the loss. It simply forwar= ds > the associated RTP and RTCP packets. In such cases, as well as if packet > loss occurs from the SRC to the SRS, the SRS SHOULD detect and attempt to > recover from the loss.=E2=80=9D > > > > Note that this still leaves other normative language in the individual > subsection. Is this okay/better? > > Something similar could be done for section 8.3, which describes differen= t > RTP session usages: > > 1. SEC using multiple m-lines > 2. SRC using mixing > > I made a couple attempts at this prior to sending this e-mail, but I was > not happy with the end results. I=E2=80=99m inclined to leave as is, but = am open to > it being reworked as well. > > > > Cheers, > > Charles > > > > > > - Alan - > > > > > > > > --f46d04182524a134260500abdbf2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Charles,

Thanks for the reply. =C2=A0 I= 'm fine with your suggestions.

- Alan -
<= div class=3D"gmail_extra">

On Fri, Aug 15= , 2014 at 8:33 AM, Hutton, Andrew <andrew.hutton@unify.com> wrote:

Alan,

=C2=A0

Could you let us know if = you are happy with the changes Charles suggests.

=C2=A0

We would like to get this= draft submitted to the IESG.

=C2=A0

Regards

Andy=

=C2=A0

=C2=A0

=C2=A0

From: siprec [= mailto:siprec-= bounces@ietf.org] On Behalf Of Charles Eckel (eckelcu)
Sent: 12 August 2014 22:43
To: Alan Johnston; siprec@ietf.org
Subject: Re: [siprec] Normative Statements in draft-ietf-siprec-prot= ocol-13

=C2=A0

Hi Alan,

=C2=A0=

Thanks for the valuable com= ments. Please see my proposed resolution for each inline.

=C2=A0=

From: Alan Johnston <alan.b.johnston@gmail.com>=
Date: Friday, July 25, 2014 at 7:50 AM
To: "sipre= c@ietf.org" <siprec@ietf.org>
Subject: [siprec] Normative Statements in draft-ietf-siprec-protocol= -13

=C2=A0=

Here's a few comments o= n some normative statements in draft-ietf-siprec-protocol-13.

=C2=A0=

"In order to communica= te most effectively, the Session Recording Client (SRC), the Session Record= ing Server (SRS), and any Recording aware User Agents (UAs) SHOULD utilize the mechanisms provided by RTP in a well-defined and predicable ma= nner."

=C2=A0=

I question whether this sta= tement should have normative language, since it isn't testable at all.<= u>

=C2=A0=

I agree. Let=E2=80=99s chan= ge to =E2=80=9Cshould=E2=80=9D.

=C2=A0=

=C2=A0=

"Using the FIR command= to recover from errors is explicitly disallowed, and instead the PLI messa= ge SHOULD be used."

=C2=A0=

The use of "disallowed= " seems like a MUST NOT, but then PLI is a SHOULD which is confusing. = =C2=A0I'd suggest using normative language instead of disallowed.

=C2=A0=

This was taken from RFC 510= 4, which reads as follows, "Using the FIR command to recover from erro= rs is explicitly disallowed, and instead the PLI message defined in AVPF [RFC4585] should be used. =C2=A0The PLI message reports lost pictu= res and has been included in AVPF for precisely that purpose.=E2=80=9D

=C2=A0=

Section 8.1.7.2 of the SIP = protocol drafts currently reads as follows, "Picture Loss Indication (= PLI), as defined in [RFC4585], informs the encoder of the loss of an undefined amount of coded video data belonging to one or more pictur= es. =C2=A0Using the FIR command to recover from errors is explicitly disall= owed, and instead the PLI message SHOULD be used. =C2=A0FIR SHOULD be used = only in situations where not sending a decoder refresh point would render the video unusable for the users.=E2=80=9D

=C2=A0=

How about we change to, &qu= ot;Picture Loss Indication (PLI), as defined in [RFC4585], informs the enco= der of the loss of an undefined amount of coded video data belonging to one or more pictures. =C2=A0[RFC4585] recommends using PLI instead of F= IR to recover from errors. FIR is appropriate only in situations where not = sending a decoder refresh point would render the video unusable for the use= rs.=E2=80=9D

=C2=A0=

=C2=A0=

There are a bunch of normat= ive statements that are repeated twice in different sections. =C2=A0For exa= mple:

=C2=A0=

"If packet loss occurs= from the UA to the SRC, the SRC SHOULD detect and attempt to recover from = the loss."=C2=A0

=C2=A0=

This statement appears in 8= .2.2 and 8.2.3 for mixer and endpoint scenarios. =C2=A0There are similar th= ings in 8.3.1 and 8.3.2. =C2=A0 Do we really want to repeat this text? =C2=A0If not, perhaps we could consolidate these two sections into three:<= u>

=C2=A0=

- Section with normative st= atements that apply to both mixing and endpoint

- Section with normative fo= r mixing only

- Section with normative fo= r endpoint only

=C2=A0=

Or, if we do want to keep t= he existing structure, maybe the normative statements could be prefixed wit= h "For RTP mixing..." or "For RTP endpoint..." so each = normative statement is unique.

=C2=A0=

Section 8.2 deals with 4 ty= pes of RTP entities:

  1. Forwarding translator
  2. Transcoding translator
  3. Mixer=C2=A0
  4. Endpoint

There is a subsection for e= ach, and as you noted, there is normative language regarding packet loss wi= thin each subsection. Normative language exists in each subsection. Each subsection is structured similarly, and as you noted, the= re is duplicated of normative language within each. I thought this helped w= ith readability from the perspective of someone implementing the spec, but = there are tradeoffs. We could pull packet loss into its own subsection that deals with all 4 types of RTP ent= ities. This might read as follows:

=C2=A0=

"Section 8.x. Packet L= oss

=C2=A0=

If packet loss occurs from = the UA to the SRC, the SRC, if acting as an =C2=A0RTP mixer or RTP endpoint= , SHOULD detect and attempt to recover from the loss. If acting as an RTP translator (either forwarding or transcoding), the SRC does dete= ct or attempt to recover from the loss. It simply forwards the associated R= TP and RTCP packets. In such cases, as well as if packet loss occurs from t= he SRC to the SRS, the SRS SHOULD detect and attempt to recover from the loss.=E2=80=9D=

=C2=A0=

Note that this still leaves= other normative language in the individual subsection. Is this okay/better= ?

Something similar could be = done for section 8.3, which describes different RTP session usages:<= u>

  1. SEC using multiple m-lines
  2. SRC using mixing

I made a couple attempts at= this prior to sending this e-mail, but I was not happy with the end result= s. I=E2=80=99m inclined to leave as is, but am open to it being reworked as well.

=C2=A0=

Cheers,

Charles

=C2=A0=

=C2=A0=

- Alan -

=C2=A0=

=C2=A0=

=C2=A0=


--f46d04182524a134260500abdbf2-- From nobody Mon Aug 25 11:30:49 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 D158C1A0218; Mon, 25 Aug 2014 11:30:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001] 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 k7WJhCds7Dae; Mon, 25 Aug 2014 11:30:38 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 110E51A0222; Mon, 25 Aug 2014 11:30:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140825183038.4220.17752.idtracker@ietfa.amsl.com> Date: Mon, 25 Aug 2014 11:30:38 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/siprec/hDJ2_gKvxI_-wRUm3NHPEPAsAvQ Cc: siprec@ietf.org Subject: [siprec] I-D Action: draft-ietf-siprec-protocol-14.txt 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: Mon, 25 Aug 2014 18:30:40 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP Recording Working Group of the IETF. Title : Session Recording Protocol Authors : Leon Portman Henry Lum Charles Eckel Alan Johnston Andrew Hutton Filename : draft-ietf-siprec-protocol-14.txt Pages : 43 Date : 2014-08-25 Abstract: This document specifies the use of the Session Initiation Protocol (SIP), the Session Description Protocol (SDP), and the Real Time Protocol (RTP) for delivering real-time media and metadata from a Communication Session (CS) to a recording device. The Session Recording Protocol specifies the use of SIP, SDP, and RTP to establish a Recording Session (RS) between the Session Recording Client (SRC), which is on the path of the CS, and a Session Recording Server (SRS) at the recording device. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-siprec-protocol/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-siprec-protocol-14 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-siprec-protocol-14 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Aug 25 12:02: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 EC0651A031B for ; Mon, 25 Aug 2014 12:02:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.169 X-Spam-Level: X-Spam-Status: No, score=-15.169 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, 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 Fc37dHqZsmp7 for ; Mon, 25 Aug 2014 12:01:59 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41B901A0308 for ; Mon, 25 Aug 2014 12:01:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2251; q=dns/txt; s=iport; t=1408993308; x=1410202908; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=idXppQJCNQYlttb/8hISd+y72sKfySWm5plRNvKQpoo=; b=Mnio2lT9QaHz0xwQJLcEnG746t41AVMlAHUFve4eDdqI6oyG0aMMHxbo wIMgMCygOABjsrtt+ogfKa3ZTIBu71+TXXzv6L7IthRuNgwcRw0NsAYUw IVhsAhFFN5ANBWzpYVEthFjdXjQHCaLacfXSgDX3yXI5pqFZ04x6v8Oki c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiAFAECH+1OtJV2P/2dsb2JhbABagw1TUwQEzEwKhnpTAYEjFneEBAEBBAEBAWsbAgEIEjQnCxcOAgQTCYg5CAW/dReOewEBHDUFhEwFimaGQIQphnqBWJM0g15sAYEOOYEHAQEB X-IronPort-AV: E=Sophos;i="5.04,398,1406592000"; d="scan'208";a="72201677" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-7.cisco.com with ESMTP; 25 Aug 2014 19:01:45 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s7PJ1j9D018155 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 25 Aug 2014 19:01:45 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.10]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0195.001; Mon, 25 Aug 2014 14:01:45 -0500 From: "Charles Eckel (eckelcu)" To: "siprec@ietf.org" Thread-Topic: [siprec] I-D Action: draft-ietf-siprec-protocol-14.txt Thread-Index: AQHPwJMuady+7mxdQUO+DUSDQJqGbZvhi1eA Date: Mon, 25 Aug 2014 19:01:44 +0000 Message-ID: References: <20140825183038.4220.17752.idtracker@ietfa.amsl.com> In-Reply-To: <20140825183038.4220.17752.idtracker@ietfa.amsl.com> 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.154.176.38] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/siprec/yJevC7ZwgdDYuP4fF5cDx3qgdhk Subject: Re: [siprec] I-D Action: draft-ietf-siprec-protocol-14.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: Mon, 25 Aug 2014 19:02:03 -0000 This update includes the changes agreed to previously on the list: http://www.ietf.org/mail-archive/web/siprec/current/msg03995.html It also updates the reference to the architecture draft, which is now RFC 7245, and replaced =B3inband=B2 with =B3in-band=B2 to make the spell checke= r happy. Cheers, Charles On 8/25/14, 11:30 AM, "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 SIP Recording Working Group of the IETF. > > Title : Session Recording Protocol > Authors : Leon Portman > Henry Lum > Charles Eckel > Alan Johnston > Andrew Hutton > Filename : draft-ietf-siprec-protocol-14.txt > Pages : 43 > Date : 2014-08-25 > >Abstract: > This document specifies the use of the Session Initiation Protocol > (SIP), the Session Description Protocol (SDP), and the Real Time > Protocol (RTP) for delivering real-time media and metadata from a > Communication Session (CS) to a recording device. The Session > Recording Protocol specifies the use of SIP, SDP, and RTP to > establish a Recording Session (RS) between the Session Recording > Client (SRC), which is on the path of the CS, and a Session Recording > Server (SRS) at the recording device. > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-siprec-protocol/ > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-ietf-siprec-protocol-14 > >A diff from the previous version is available at: >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-siprec-protocol-14 > > >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. > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >siprec mailing list >siprec@ietf.org >https://www.ietf.org/mailman/listinfo/siprec From nobody Wed Aug 27 13:28:45 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 EE2251A6F1A for ; Wed, 27 Aug 2014 13:28:43 -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 A5b2Wwot3tJJ for ; Wed, 27 Aug 2014 13:28:42 -0700 (PDT) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id 379B61A6F11 for ; Wed, 27 Aug 2014 13:28:42 -0700 (PDT) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta05.westchester.pa.mail.comcast.net with comcast id jn311o0071ap0As55wUhhJ; Wed, 27 Aug 2014 20:28:41 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by omta22.westchester.pa.mail.comcast.net with comcast id jwUh1o00Q3Ge9ey3iwUhXi; Wed, 27 Aug 2014 20:28:41 +0000 Message-ID: <53FE3F79.6020607@alum.mit.edu> Date: Wed, 27 Aug 2014 16:28:41 -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: <20140827201915.8934.86458.idtracker@ietfa.amsl.com> In-Reply-To: <20140827201915.8934.86458.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20140827201915.8934.86458.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1409171321; bh=yz/ZOf7/07/mA5YDLqzRtA7OdTkkrW3sSl0DG+SQcsg=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=gNvf45iVP4xpgF0nCxuwWiryyWaAugVsRmP/6BPPyO2WTtCwAiNXWW55xwEwZe6wH VrMh+h9X/iaDvbCS8ESLv9zweO1SE9WmIHaMKfgnnfL6kDEZaG/McXuxdDHTS8HMnF e12KfICuD+Z6kP94cCTaQNt6FTsZhP6eY+yS4RdoPYfNlgDA+Q/jn//FYEZoL9O0v1 3rIeu2bNX5n4Yhg/qCJvvMYgJfppDHEX3WHhyM+4WSWgRsLSopOnQ2kLSEdYhdQ4oP ZywvnT4hEtT9Vrm++R2h6wO/xJC+YQAJS5AqGZQDFvlkqhIc8MRyVqrb7IaZq1ZGu+ Nby1LGdf4oUWA== Archived-At: http://mailarchive.ietf.org/arch/msg/siprec/OSPjPmw7sjo4wyKmoDyjDGdSwdw Subject: [siprec] New Version Notification for draft-yan-siprec-msrp-recording-02.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: Wed, 27 Aug 2014 20:28:44 -0000 I just submitted a revised version of the MSRP recording draft. The following is a summary of what is different in this version. (It is in the draft too.) This version addresses comments received on the -01 version, both on the mailing list and at IETF90. The following is my list of things to address: o Define a new MIME type that is used to wrap the CS MSRP messages that are being recorded. This allows the original message to be left as-is, so it is always clear what it was. While CPIM could be used for this, defining a new type will allow capturing other necessary metadata. o Need to further consider the need to track message timing. Can the timing of messages received by the SRS on the RS MSRP stream be considered a sufficient proxy for the timing of messages in the CS, or should we explicitly pass timestamps of messages as received on the CS? (The issue was raised but not decided.) o We need to clarify that there is no guarantee that messages received on the CS have been recorded. o It was agreed that there is no need to record the MSRP URIs that are used to establish the CS MSRP session. o It is important that we maintain a 1:1 consistency between MSRP MESSAGE-IDs used in recorded CS sessions and the MESSAGE-IDs used in the RS. But we should not violate MSRP by using the same MESSAGE-IDs. We came up with the idea of adding an SRC-specific prefix to the CS message ids to create unique ones for the RS. This should be done in a standard way so that the SRS can recover the original CS message ids, in order to support correlation across redundant SRCs. o Will need to work out the details of what happens when a CS MSRP session is terminated with an incomplete message. It will be necessary to send the incomplete message to the SRS, but must it appear to be incomplete within the SRS MSRP session? o There are a variety of reasons why the SRC may not want, or be able to, record individual messages in the CS session. (One example is because the message size is greater than the maximum indicated by the SRS. Another is because the mime type of the message is a type that the SRS did not indicate support for.) There should be a type of placeholder message that can be sent to the SRS to indicate a message has been dropped, why, and some key attributes about the message. The new SIPREC wrapper mime type could be designed to serve this purpose. o REPORT messages on the CS can't be sent directly on the RS. The new SIPREC wrapper mime type could also serve as a way to encapsulate those. The primary change is to introduce a new wrapper MIME type ("application/msrp-recording") that is used in RS MSRP sessions for all CS MSRP messages that are to be recorded. This is used with SEND messages whether they have a CPIM wrapper or not. It also allows non-SEND messages from the CS to be sent intact in the RS for recording. And it provides a vehicle for carrying other data as needed. Adding another layer of wrapper could substantially increase the total amount of data send on the RS session, relative to what is present on the CS. I've tried to mitigate that via the details of the design. For SEND messages, only the body of the SEND message is wrapped. And From and To headers in this wrapper can be omitted in cases where that information is redundant. I've assumed that messages other than SEND should in general be infrequent enough that extra overhead when sending them isn't worth a lot of concern. This wrapper can carry a DateTime header. This provides a mechanism to address the timestamp issues. I've left it as optional to use. I clarified the non-guarantee of recording in the architecture section. I've provided a special header in the wrapper to carry the MESSAGE-ID from SEND messages in the CS. And SEND messages will get a separate MESSAGE-ID on the RS MSRP session when sent to the SRS. This provides the SRS with enough information to solve the correlation problem when a message is incomplete in one CS MSRP session and is resumed on another. (The problem of reassembly is left to the SRS.) The wrapper format includes a mechanism for the SRC to report dropped messages to the SRS. The wrapper format also includes a mechanism for encapsulating CS REPORT messages for sending to the SRS. I realized that this level of wrapping provides an opportunity to multiplex unrelated CS MSRP sessions on a single RS MSRP session. To allow this I've provided a way to include the session-id from the metadata, that identifies the particular CS MSRP session, as a value in the wrapper of the message sent on the RS. But I also made that optional when it is redundant. This gives a choice: multiplex but make the messages bigger, or create a separate RS MSRP session for each CS MSRP session and keep the messages smaller. I've included this as a trial balloon for discussion. I'm undecided about it. The formatting of all of this could be better. But for now I just wanted to get the basic concepts down for review. Once the approach is reasonably well worked out I'll try to improve the formatting. There are many places here where I am uncertain what normative strength to apply to individual requirements. I've indicated this inline for many of those. Please comment on this. I believe this is in line with what was discussed in Toronto. I especially want to hear whether people find this an acceptable direction, as well as thoughts on the details. And anything I might have overlooked that still needs to be addressed. Thanks, Paul -------- Original Message -------- Subject: New Version Notification for draft-yan-siprec-msrp-recording-02.txt Date: Wed, 27 Aug 2014 13:19:15 -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-02.txt has been successfully submitted by Paul H. Kyzivat and posted to the IETF repository. Name: draft-yan-siprec-msrp-recording Revision: 02 Title: Overview for MSRP Recording based on SIPREC Document date: 2014-08-27 Group: Individual Submission Pages: 17 URL: http://www.ietf.org/internet-drafts/draft-yan-siprec-msrp-recording-02.txt Status: https://datatracker.ietf.org/doc/draft-yan-siprec-msrp-recording/ Htmlized: http://tools.ietf.org/html/draft-yan-siprec-msrp-recording-02 Diff: http://www.ietf.org/rfcdiff?url2=draft-yan-siprec-msrp-recording-02 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