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

> -----Original Message-----
> From: Parthasarathi R [mailto:partha@parthasarathi.co.in]
> Sent: Wednesday, November 07, 2012 12:35 PM
> To: Charles Eckel (eckelcu); siprec@ietf.org
> Subject: RE: [siprec] FW: New Version Notification for draft-ram-siprec-
> callflows-02.txt
> 
> Hi Charles,
> 
> Thanks a lot for your review. Please read inline.
> 
> Thanks
> Partha
> 
> -----Original Message-----
> From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com]
> Sent: Saturday, November 03, 2012 10:32 PM
> To: Parthasarathi R; siprec@ietf.org
> Subject: RE: [siprec] FW: New Version Notification for
> draft-ram-siprec-callflows-02.txt
> 
> 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
> 
> <Partha> I'll updated in the next revision </Partha>
> 
> 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.
> 
> <Partha> Text will be updated to indicate the typical metadata body in the
> next revision. </Partha>
> 
> 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).
> <Partha> Could you explain this comment as Section 4 is security
> consideration in -02 draft. My guess is that your comment is based on -01
> draft. </Partha>

Yes, you are correct. Sorry about that. And yes, the way the -02 drafts addresses it works for me.

> 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).
> 
> <Partha> 5, 6, 7 comments will be incorporated in the next revision
> </Partha>
> 
> 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?
> 
> <Partha> Because it is mixed stream. There is no way to distinguish the
> directionality of the individual participants. </Partha>
> 
>  Also, how do you indicate when each person is talking?
> <Partha> It is possible that the information may be lost at SRC itself
> </Partha>

This is troubling to me, but perhaps I am the only one that cares. I also tend to think I do not understand the turret case well enough at this point. Maybe someone here at IETF 85 this week can set me straight.

Cheers,
Charles

> Is it accomplished using CNAME and SSRC?
> <Partha> I'm not sure whether CNAME & SSRC will help for mixed stream
> </Partha>
> 
> 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