RE: [siprec] Last Call: <draft-ietf-siprec-req-09.txt>(Use Cases andRequirements for SIP-based MediaRecording (SIPREC)) toInformational RFC
"Ram Mohan R (rmohanr)" <rmohanr@cisco.com> Thu, 14 April 2011 16:42 UTC
Return-Path: <rmohanr@cisco.com>
X-Original-To: ietf@ietfc.amsl.com
Delivered-To: ietf@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 22A02E079C; Thu, 14 Apr 2011 09:42:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.517
X-Spam-Level:
X-Spam-Status: No, score=-10.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yt+FANOOE2vD; Thu, 14 Apr 2011 09:42:43 -0700 (PDT)
Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfc.amsl.com (Postfix) with ESMTP id 2ED66E0663; Thu, 14 Apr 2011 09:42:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rmohanr@cisco.com; l=7021; q=dns/txt; s=iport; t=1302799363; x=1304008963; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=6rUe3sEq4q/mACJdc92WAmc4p0YxXstExn5GPFIStGw=; b=mJsXDRQu1mfYueGrh0+2SgYlHp8ANlg218gJfXYMxzzR26m3TlIPg00o Zx5LpMvHWrUbGSc70v2uRRpFfS76emJ6MmdTJb9+drltcxmZrMIe8vm9S 4vgHesS8qxGwSXz/FfsbynMWVnSyD6fOIWJLuexGqOY300afJUBQm1GAm k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AuQAAP8ip02Q/khNgWdsb2JhbACXeY19FAEBFiYlpEOcfoIhg00EhViMEQ
X-IronPort-AV: E=Sophos;i="4.64,212,1301875200"; d="scan'208";a="25742336"
Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 14 Apr 2011 16:42:42 +0000
Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p3EGgfs1007873; Thu, 14 Apr 2011 16:42:41 GMT
Received: from xmb-bgl-417.cisco.com ([72.163.129.213]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 14 Apr 2011 22:12:40 +0530
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [siprec] Last Call: <draft-ietf-siprec-req-09.txt>(Use Cases andRequirements for SIP-based MediaRecording (SIPREC)) toInformational RFC
Date: Thu, 14 Apr 2011 22:12:39 +0530
Message-ID: <35BCE99A477D6A4986FB2216D8CF2CFD06009D00@XMB-BGL-417.cisco.com>
In-Reply-To: <07465C1D981ABC41A344374066AE1A2C38AB73D110@TLVMBX01.nice.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [siprec] Last Call: <draft-ietf-siprec-req-09.txt>(Use Cases andRequirements for SIP-based MediaRecording (SIPREC)) toInformational RFC
Thread-Index: Acv0WYBeRuGjGNBtTZSHeqn78QP5xwGEv6YwAAlHtwAAAvtH0AABcMXAAAdJn6AAAIZ7cA==
References: <20110406125020.17538.70016.idtracker@localhost><1D062974A4845E4D8A343C65380492020533BB70@XMB-BGL-414.cisco.com><A444A0F8084434499206E78C106220CA0875EB5A4E@MCHP058A.global-ad.net><07465C1D981ABC41A344374066AE1A2C38AB73D00B@TLVMBX01.nice.com><A444A0F8084434499206E78C106220CA0875EB5B28@MCHP058A.global-ad.net> <07465C1D981ABC41A344374066AE1A2C38AB73D110@TLVMBX01.nice.com>
From: "Ram Mohan R (rmohanr)" <rmohanr@cisco.com>
To: Leon Portman <Leon.Portman@nice.com>, "Elwell, John" <john.elwell@siemens-enterprise.com>, "Muthu ArulMozhi Perumal (mperumal)" <mperumal@cisco.com>, ietf@ietf.org
X-OriginalArrivalTime: 14 Apr 2011 16:42:40.0734 (UTC) FILETIME=[F8587FE0:01CBFAC2]
X-Mailman-Approved-At: Fri, 15 Apr 2011 07:54:25 -0700
Cc: siprec@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Apr 2011 16:42:45 -0000
We already have attributes Start-Time / End-time in Media Stream block. This is for the same purpose to indicate the wall clock time for start/end of media. Ram > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Leon Portman > Sent: Thursday, April 14, 2011 9:57 PM > To: Elwell, John; Muthu ArulMozhi Perumal (mperumal); ietf@ietf.org > Cc: siprec@ietf.org > Subject: Re: [siprec] Last Call: <draft-ietf-siprec-req-09.txt>(Use > Cases andRequirements for SIP-based MediaRecording (SIPREC)) > toInformational RFC > > I am not sure that having wall clock only for CS start is enough, > especially for partial metadata update. I will prefer to have on media > level > > Leon > > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > Sent: Thursday, April 14, 2011 3:58 PM > To: Leon Portman; Muthu ArulMozhi Perumal (mperumal); ietf@ietf.org > Cc: siprec@ietf.org > Subject: RE: [siprec] Last Call: <draft-ietf-siprec-req-09.txt> (Use > Cases andRequirements for SIP-based Media Recording (SIPREC)) > toInformational RFC > > Understood, but if we have wall clock time for the start of a CS, > wouldn't that be sufficient? The new requirement would cover > synchronization of all media start/stops relative to that time. > > John (as individual) > > > > -----Original Message----- > > From: Leon Portman [mailto:Leon.Portman@nice.com] > > Sent: 14 April 2011 13:19 > > To: Elwell, John; Muthu ArulMozhi Perumal (mperumal); ietf@ietf.org > > Cc: siprec@ietf.org > > Subject: RE: [siprec] Last Call: > > <draft-ietf-siprec-req-09.txt> (Use Cases andRequirements for > > SIP-based Media Recording (SIPREC)) toInformational RFC > > > > Actually REQ-022 and REQ-023 describing not only requirement to > > synchronize between different media streams but more importantly > > ability to relate them to real world (wall) clock. It is not only > > important to playback them correctly but also to know when it was > > said. > > One example is continue trading after closing hour (even for one > > second is not allowed) > > > > And if these media are synchronized to wall clock then they are also > > synchronized between them thus I am not sure if we need this > > additional requirement. > > > > Thanks > > > > Leon > > > > -----Original Message----- > > From: siprec-bounces@ietf.org > > [mailto:siprec-bounces@ietf.org] On Behalf Of Elwell, John > > Sent: Thursday, April 14, 2011 1:54 PM > > To: Muthu ArulMozhi Perumal (mperumal); ietf@ietf.org > > Cc: siprec@ietf.org > > Subject: Re: [siprec] Last Call: > > <draft-ietf-siprec-req-09.txt> (Use Cases andRequirements for > > SIP-based Media Recording (SIPREC)) toInformational RFC > > > > > > > > > > > -----Original Message----- > > > From: siprec-bounces@ietf.org > > > [mailto:siprec-bounces@ietf.org] On Behalf Of Muthu > > ArulMozhi Perumal > > > (mperumal) > > > Sent: 14 April 2011 07:34 > > > To: ietf@ietf.org > > > Cc: siprec@ietf.org > > > Subject: Re: [siprec] Last Call: > > > <draft-ietf-siprec-req-09.txt> (Use Cases andRequirements for > > > SIP-based Media Recording (SIPREC)) toInformational RFC > > > > > > I've one major comment. It draft discusses synchronization > > between the > > > recorded media streams and synchronized playback, which > > seem important > > > for certain applications: > > > > > > <snip> > > > Some applications require the recording of more than one > > media stream, > > > possibly of different types. Media are synchronized, either > > at storage > > > or at playback. > > > </snip> > > > > > > However, in the requirements section it doesn't seem REQ-022 and > > > REQ-023 are all that are need and sufficient to achieve this with > > > needed precision. So, I would suggest adding another requirement as > > > follows: > > > The mechanism MUST provide means for facilitating > > synchronization of > > > the recorded media streams and metadata either at storage or at > > > playback. > > > This includes, but not limited to, the information needed as per > > > REQ-022 and REQ-023. > > [JRE] This seems a reasonable addition. I wonder if the new > > requirement (first sentence only) is sufficient as a > > **replacement** for REQ-022 and REQ-023. On reading REQ-022 and > > REQ-023 again, it is not so clear what their purpose was, and they > > seem to be more like a solution than a requirement. > > One purpose would certainly be that covered by Muthu's new > > requirement. Was there any other purpose? > > > > John > > > > > > > > A nitpick: > > > Use Case 8 > > > In cases where calls inside or between branches must be recorded, a > > > centralized recording system in data centers together with > > telephony > > > infrastructure (e.g. PBX) me deployed. > > > > > > s/me/may be > > > > > > Muthu > > > > > > |-----Original Message----- > > > |From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > > Behalf Of The IESG > > > |Sent: Wednesday, April 06, 2011 6:20 PM > > > |To: IETF-Announce > > > |Cc: siprec@ietf.org > > > |Subject: [siprec] Last Call: <draft-ietf-siprec-req-09.txt> > > > (Use Cases > > > andRequirements for SIP-based > > > |Media Recording (SIPREC)) toInformational RFC > > > | > > > | > > > |The IESG has received a request from the SIP Recording WG > > (siprec) to > > > |consider the following document: > > > |- 'Use Cases and Requirements for SIP-based Media > > Recording (SIPREC)' > > > | <draft-ietf-siprec-req-09.txt> as an Informational RFC > > > | > > > |The IESG plans to make a decision in the next few weeks, > > and solicits > > > |final comments on this action. Please send substantive > > > comments to the > > > |ietf@ietf.org mailing lists by 2011-04-20. Exceptionally, > > > comments may > > > be > > > |sent to iesg@ietf.org instead. In either case, please retain the > > > |beginning of the Subject line to allow automated sorting. > > > | > > > |The file can be obtained via > > > |http://datatracker.ietf.org/doc/draft-ietf-siprec-req/ > > > | > > > |IESG discussion can be tracked via > > > |http://datatracker.ietf.org/doc/draft-ietf-siprec-req/ > > > | > > > | > > > | > > > |No IPR declarations have been submitted directly on this I-D. > > > |_______________________________________________ > > > |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 > > > > > _______________________________________________ > > 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
- RE: [siprec] Last Call: <draft-ietf-siprec-req-09… Muthu ArulMozhi Perumal (mperumal)
- RE: [siprec] Last Call: <draft-ietf-siprec-req-09… Elwell, John
- RE: [siprec] Last Call: <draft-ietf-siprec-req-09… Leon Portman
- RE: [siprec] Last Call: <draft-ietf-siprec-req-09… Elwell, John
- RE: [siprec] Last Call: <draft-ietf-siprec-req-09… Leon Portman
- RE: [siprec] Last Call: <draft-ietf-siprec-req-09… Muthu ArulMozhi Perumal (mperumal)
- RE: [siprec] Last Call: <draft-ietf-siprec-req-09… Elwell, John
- RE: [siprec] Last Call: <draft-ietf-siprec-req-09… Ram Mohan R (rmohanr)
- RE: [siprec] Last Call:<draft-ietf-siprec-req-09.… Charles Eckel (eckelcu)
- RE: [siprec] LastCall:<draft-ietf-siprec-req-09.t… Parthasarathi R (partr)
- RE: [siprec] LastCall:<draft-ietf-siprec-req-09.t… Charles Eckel (eckelcu)
- RE: [siprec] Last Call: <draft-ietf-siprec-req-09… Muthu ArulMozhi Perumal (mperumal)
- RE: [siprec] Last Call:<draft-ietf-siprec-req-09.… Leon Portman
- RE: [siprec] Last Call:<draft-ietf-siprec-req-09.… Parthasarathi R (partr)
- RE: [siprec] Last Call:<draft-ietf-siprec-req-09.… Elwell, John
- RE: [siprec] Last Call:<draft-ietf-siprec-req-09.… Muthu ArulMozhi Perumal (mperumal)