Re: [siprec] FW: New Version Notification for draft-ram-siprec-callflows-02.txt

"Charles Eckel (eckelcu)" <eckelcu@cisco.com> Sat, 03 November 2012 17:02 UTC

Return-Path: <eckelcu@cisco.com>
X-Original-To: siprec@ietfa.amsl.com
Delivered-To: siprec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F66721F9C34 for <siprec@ietfa.amsl.com>; Sat, 3 Nov 2012 10:02:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LqhKFzH6uDNj for <siprec@ietfa.amsl.com>; Sat, 3 Nov 2012 10:02:02 -0700 (PDT)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 332CB21F9ADF for <siprec@ietf.org>; Sat, 3 Nov 2012 10:02:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5093; q=dns/txt; s=iport; t=1351962122; x=1353171722; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=IAOHY0ZstpWtromMHuj6AIS4kozc70Hu7HwshVKbSJo=; b=MrBWiO2Tfw9NKO+CGTkyH5+17YnvNMFAQG+UqeFvth7wvZNBqZYBPUoc DRdPO7XCZAiRQKJrkeY1TtRXsxpAS2d4iPKQc862XpjRYWstkFTWaGqBl ADwpNK8wfOCFNeb4hdSONK82gbAFBl0cGhOzrdMeGRdtH4jI0aYDk0ZXi I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EAC9NlVCtJV2Z/2dsb2JhbABEwzWBCIIeAQEBBAEBAQ8BJzQJDgQCAQgRBAEBCxQJBycLFAgBCAEBBAESCAEZh2gLmV2fTYwBhVthA5cXjT2Ba4Jvghk
X-IronPort-AV: E=Sophos;i="4.80,705,1344211200"; d="scan'208";a="138469999"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-7.cisco.com with ESMTP; 03 Nov 2012 17:02:01 +0000
Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id qA3H21JK009021 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 3 Nov 2012 17:02:01 GMT
Received: from xmb-aln-x08.cisco.com ([169.254.3.25]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0318.001; Sat, 3 Nov 2012 12:02:00 -0500
From: "Charles Eckel (eckelcu)" <eckelcu@cisco.com>
To: Parthasarathi R <partha@parthasarathi.co.in>, "siprec@ietf.org" <siprec@ietf.org>
Thread-Topic: [siprec] FW: New Version Notification for draft-ram-siprec-callflows-02.txt
Thread-Index: Ac2wex0ks8AbuINQQK24PeueYzN4BQAAie+QAlkjWwA=
Date: Sat, 03 Nov 2012 17:02:00 +0000
Message-ID: <92B7E61ADAC1BB4F941F943788C088281041F4@xmb-aln-x08.cisco.com>
References: <008901cdb07e$78ff0840$6afd18c0$@co.in>
In-Reply-To: <008901cdb07e$78ff0840$6afd18c0$@co.in>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.21.149.187]
x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19336.001
x-tm-as-result: No--61.032600-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [siprec] FW: New Version Notification for draft-ram-siprec-callflows-02.txt
X-BeenThere: siprec@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Recording Working Group Discussion List <siprec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/siprec>, <mailto:siprec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/siprec>
List-Post: <mailto:siprec@ietf.org>
List-Help: <mailto:siprec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/siprec>, <mailto:siprec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 03 Nov 2012 17:02:03 -0000

Hi draft authors, 

I read the draft and have a few comments to share.

1) abstract
s/model defined the metadata draft/model defined in the metadata draft

2) overview
s/not normative on any aspect of SIP/not normative on any aspect of SIPREC

3) Section 3.1 reads, "The following example provides all the tuples ..."
IMO, this sounds as if it provides an exhaustive list; however, I do not think that is the intent. Rather, I think it provides an example of metadata that may be included in a typical metadata body. It would be good to be clean on the intent so that the example is read in the proper from of mind.

4) Section 3.1. It would be helpful to explain the call scenario to which the metadata example applies. For example, it appears to be  a two party call with 4 streams per participant, 2 in each direction (e.g. one for audio and one for video). Alternatively, you can remove this example as it appears to be a duplicate of the next example (in section 4).

5) Section 4.2
s/Media Streams sent by each participant is received all/Media streams sent by each participant are received by the
s/snippets of SDP is shown/snippets of SDP are shown

6) Section 4.3, example 2, it would be better if you remain consistent with the participant names (i.e. A/B or Ram/Partha.

7) F4, it would be helpful to explain the inactive and sendonly SDP attributes by adding text explaining that during the hold, A stops sending streams (inactive), while B continues sending (sendonly).

8) Section 4.4, metadata
Is the idea that the streams remain the same and only the participant changes? If so, state that. It is hard to tell by visual inspection whether the stream id is an exact match of perhaps has some small change. Also, I was expecting to see metadata saying the Ram left and providing a disassociation time. Instead, this is provided only the end of the call. Is that done just in case Ram returns before the end of the call. In any case, it would be good to state the reasoning so that it is clear why the metadata is as it is.

9) Section 4.6, F1
Why does <send> stream == <recv> stream? Also, how do you indicate when each person is talking? Is it accomplished using CNAME and SSRC?

Cheers,
Charles 

> -----Original Message-----
> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf
> Of Parthasarathi R
> Sent: Monday, October 22, 2012 1:56 PM
> To: siprec@ietf.org
> Subject: [siprec] FW: New Version Notification for draft-ram-siprec-
> callflows-02.txt
> 
> Hi all,
> 
> draft-ram-siprec-callflows-02 is published with the following update:
> 
> 1) Updated the callflow as per draft-ietf-siprec-metadata-08
> 2) Removed Metadata Example section
> 3) Incorporated Ofir Rath review comments
> 
> The current open issue in the drafts
> 1) Incorporating RS SIP messages with metadata XML messages for all
> callflow
> 2) Callflows provided by Ofir Rath has to be discussed and added.
> 
> Could you please provide your valuable comments on
> draft-ram-siprec-callflows-02.
> 
> Thanks
> Partha
> 
> -----Original Message-----
> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
> Sent: Monday, October 22, 2012 11:02 PM
> To: partha@parthasarathi.co.in
> Cc: rmohanr@cisco.com; pkyzivat@alum.mit.edu
> Subject: New Version Notification for draft-ram-siprec-callflows-02.txt
> 
> 
> A new version of I-D, draft-ram-siprec-callflows-02.txt
> has been successfully submitted by Parthasarathi Ravindran and posted to
> the
> IETF repository.
> 
> Filename:	 draft-ram-siprec-callflows
> Revision:	 02
> Title:		 Session Initiation Protocol (SIP) Recording Call Flows
> Creation date:	 2012-10-22
> WG ID:		 Individual Submission
> Number of pages: 18
> URL:             http://www.ietf.org/internet-drafts/draft-ram-siprec-callflows-
> 02.txt
> Status:          http://datatracker.ietf.org/doc/draft-ram-siprec-callflows
> Htmlized:        http://tools.ietf.org/html/draft-ram-siprec-callflows-02
> Diff:            http://www.ietf.org/rfcdiff?url2=draft-ram-siprec-callflows-02
> 
> 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 lists call flows that has snapshot
>    of metadata sent from SRC to SRS, the metadata format for which is
>    described in [I-D.ietf-siprec-metadata] .  This is purely an
>    informational document that is written to support the model defined
>    the metadata draft.
> 
> 
> 
> 
> The IETF Secretariat
> 
> _______________________________________________
> siprec mailing list
> siprec@ietf.org
> https://www.ietf.org/mailman/listinfo/siprec