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

[Paul Kyzivat <[e-mail]>]

On 1/1/13 10:57 AM, Parthasarathi R wrote:
> Hi Charles,
>
> After a long time, I'm looking to this mail thread and understand that there
> is a non-closed item on metadata mixing representation. As per the current
> model, SRC mixing will leads to the loss of data like "who is the current
> contributor of the mixed media". We have tried to use CSRC earlier and not
> accepted as a generic solution. In case any other alternative exists to
> solve this issue, Please let us know.

On "solution" is just to acknowledge it as a limitation.

	Thanks,
	Paul

> Hope Turret case solution is clarified to you.
>
> Thanks
> Partha
>
>> -----Original Message-----
>> From: Charles Eckel (eckelcu) [mailto:[e-mail]]
>> Sent: Wednesday, November 07, 2012 11:23 PM
>> To: Parthasarathi R; [e-mail]
>> Subject: RE: [siprec] FW: New Version Notification for draft-ram-
>> siprec-callflows-02.txt
>>
>>> -----Original Message-----
>>> From: Parthasarathi R [mailto:[e-mail]]
>>> Sent: Wednesday, November 07, 2012 12:35 PM
>>> To: Charles Eckel (eckelcu); [e-mail]
>>> 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:[e-mail]]
>>> Sent: Saturday, November 03, 2012 10:32 PM
>>> To: Parthasarathi R; [e-mail]
>>> 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: [e-mail] [mailto:[e-mail]] On
>>> Behalf
>>>> Of Parthasarathi R
>>>> Sent: Monday, October 22, 2012 1:56 PM
>>>> To: [e-mail]
>>>> 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: [e-mail] [mailto:[e-mail]]
>>>> Sent: Monday, October 22, 2012 11:02 PM
>>>> To: [e-mail]
>>>> Cc: [e-mail]; [e-mail]
>>>> 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
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/siprec
>
> _______________________________________________
> siprec mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/siprec
>