Re: [dispatch] Comments on draft-jain-dispatch-session-recording-protocol-req-00
Leon Portman <Leon.Portman@nice.com> Sun, 26 July 2009 02:10 UTC
Return-Path: <Leon.Portman@nice.com>
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F7933A69E6 for <dispatch@core3.amsl.com>; Sat, 25 Jul 2009 19:10:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.495
X-Spam-Level:
X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gw2cQx50vsEk for <dispatch@core3.amsl.com>; Sat, 25 Jul 2009 19:10:12 -0700 (PDT)
Received: from mailil.nice.com (unknown [192.114.148.38]) by core3.amsl.com (Postfix) with ESMTP id 4DC2A3A6A0A for <dispatch@ietf.org>; Sat, 25 Jul 2009 19:10:11 -0700 (PDT)
Received: from TLVMBX01.nice.com ([192.168.253.242]) by tlvcas01.nice.com ([192.168.253.111]) with mapi; Sun, 26 Jul 2009 05:10:09 +0300
From: Leon Portman <Leon.Portman@nice.com>
To: Alan Johnston <alan@sipstation.com>, "dispatch@ietf.org" <dispatch@ietf.org>
Date: Sun, 26 Jul 2009 05:10:08 +0300
Thread-Topic: [dispatch] Comments on draft-jain-dispatch-session-recording-protocol-req-00
Thread-Index: AcoMjLJ6ThzVzaclTwCm7I3jEBcc0QBBkppw
Message-ID: <07465C1D981ABC41A344374066AE1A2C37D51541F2@TLVMBX01.nice.com>
References: <4A69FD6A.4020205@sipstation.com>
In-Reply-To: <4A69FD6A.4020205@sipstation.com>
Accept-Language: en-US, he-IL
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US, he-IL
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [dispatch] Comments on draft-jain-dispatch-session-recording-protocol-req-00
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 26 Jul 2009 02:10:13 -0000
Alan, Hi Thanks for the comments. Please see below my answers Regards Leon -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Alan Johnston Sent: Friday, July 24, 2009 9:29 PM To: dispatch@ietf.org Subject: [dispatch] Comments on draft-jain-dispatch-session-recording-protocol-req-00 Here are my comments on this draft. Overall, I think this draft is an excellent start at the requirements for this important topic. I look forward to future discussions of charter text so we can get started on the work. Section 2: " Another, related IETF draft is draft-wing-sipping-srtp-key [I-D.wing-sipping-srtp-key], which describes an approach for providing SRTP session keys to a recorder-type server. That draft focuses on the mechanism to provide the SRTP session key, rather than the mechanism to invoke and sustain recording sessions themselves." draft-wing-sipping-srtp-key actually has a lot of discussion, including call flows showing how recording sessions can be established. Also, this document has four recording modes discussed, which I think should be discussed in this document. Two are mentioned without really explaining them, and two others are implied by various requirements. [LeonP] Yes, for the protocol draft, we will need to combine all of the approaches and make sure that we covered all use cases Section 3: " Recording Session: The session created between an RC and RS for the purpose of recording a Recorded Session. The Recorded Session may itself be based on SIP, but it is a separate session from the Recording Session. Recorded Session: A session created between a UAC and UAS that is recorded by the RC and RS systems." These two terms only differ by their tense, yet I think one refers to a signaling session and the other refers to a media session. If so, better terms and definitions are needed. If not, we need a term for the actual recorded media. Also, there are (at least) two sessions here - the one between the UAs and the Recording Session - in a few places I suspect the two are being confused. [LeonP] Actually Recording Session relates to both SIP and Media that is forked to the recording server and Recorded Session is actually the original conversation between two UAs. These two are exactly the two sessions that you are describing. " Dynamic Recording: Dynamic recording is a mode of recording where the recording sessions are established on an as needed basis. The length of these sessions is typically same as the length of the actual media sessions. Persistent Recording: Persistent recording is a mode of recording where the recording sessions are established at system start-up and kept-alive from that point on. The length of these sessions is independent from the length of the actual recorded media sessions. Persistent recording sessions avoid issues such as media clipping that can occur due to delays in recording session establishment." These terms need more explanation as I can think of multiple things they might mean. For example, when you say "session" do you mean a signaling session or media session? When you talk about avoiding media clipping, do you mean that media is always sent by the RC to the RS regardless of whether there is any media? [LeonP] Yes, by session we mean both legs: signaling and media. And in Persistent Recording mode, the Recording SIP session supposed to stay connected even there is not actual connected sessions for the specific recorded UA. Figures could use Figure numbers and labels. Also, it would be worth showing which is the RC and which is the RS in them. Section 5 " o REQ-001 The mechanism MUST support the ability to perform persistent (always-on) or dynamic (on-demand) Recording Sessions." I'm not sure that the Persistent and Dynamic Recording as defined above correspond to the Always On and On Demand modes defined in http://tools.ietf.org/html/draft-wing-sipping-srtp-key-04#section-4. [LeonP] It is different in the way that the Recording Session is established only once during initialization (or login events) and then only media is forwarded per each call in order to minimize the clipping. " o REQ-002 The mechanism MUST support the ability to perform persistent Recording Sessions, such that the connection and attributes of media in the Recording Session are not dynamically signaled for each Recorded Session before it can be recorded. Call details and metadata will still be signaled, but can be post- correlated to the recorded media. There will still need to be a means of correlating the recorded media connection/packets to the Recorded Session, however this may be on a permanent filter-type basis, such as based on a SIP AoR of an agent that is always recorded, or based on identifiers in the recorded media itself." Without fully understanding Persistent Recording, I can't evaluate this requirement. " o REQ-009 The mechanism MUST support the ability to deliver mixed media streams to the RS. The RS MAY be informed about the composition of the mixed streams through session metadata. Note: A mixed media stream is where several recorded sessions are carried in a single recording session. A mixed media stream is typically produced by a mixer function." I'm not clear what mixed media means here - does it mean a mix of media types - synchronized audio and video from the same session, or do you mean multiple media streams from different sessions? The note seems to indicate that this relates only to a conference call where multiple sources (SSRCs) have been combined into a single RTP session. [LeonP] It is specific trading floor environment requirements where multiple handset and speakers for specific turrets will be mixed on the turret level for recording by one recording channel. " o REQ-013 The mechanism MUST support the ability to inject tones into the Recorded Session either from the RS or from the RC." Recorded Session seems to be defined as the media between the RC and RS. Is that where the injected tones should be? Or should then be mixed in the media between the two UAs? [LeonP] we have multiple options here. Preferable solution that one of the UAs will inject them (triggered by policy or parameters in SRP), but there are also configuration where RS will be required to create them and send back to RC (like talking clock for example) " o REQ-021 The mechanism MUST support the ability for the RC to only perform media replication to the RS, without needing to decode or mix audio/video/etc., and without needing to be an RTP agent. This will allow the RC to replicate media at layers below RTP. Clearly, such an RC mode would not be able to provide transcoding, or media injection from the RS back into the Recorded Session." Does this mean that you think that RTP is unsuitable for transporting media between the RS and RC? Clearly it isn't for IM, but I would think that many of the functions of RTP are needed for audio and video media. To understand this requirement will take more discussion. [LeonP] Actually it was Hadriel requirement. I believe it only means that RC does not required to implement RTP stack, it can just fork RTP packets on the network level (by hardware) Thanks, Alan _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch
- [dispatch] Comments on draft-jain-dispatch-sessio… Alan Johnston
- Re: [dispatch] Comments on draft-jain-dispatch-se… Leon Portman
- Re: [dispatch] Comments on draft-jain-dispatch-se… Alan Johnston
- Re: [dispatch] Comments on draft-jain-dispatch-se… Roni Even
- Re: [dispatch] Comments on draft-jain-dispatch-se… Labarbera, Chris
- Re: [dispatch] Comments on draft-jain-dispatch-se… Doken, Serhad
- Re: [dispatch] Comments on draft-jain-dispatch-se… Jain, Rajnish
- Re: [dispatch] Comments on draft-jain-dispatch-se… Sanjay Sinha (sanjsinh)
- Re: [dispatch] Comments on draft-jain-dispatch-se… Jain, Rajnish
- Re: [dispatch] Comments on draft-jain-dispatch-se… Doken, Serhad