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

["Charles Eckel (eckelcu)" <[e-mail]>]

Hi Partha,

Please see inline.

> -----Original Message-----
> From: Parthasarathi R [mailto:[e-mail]]
> Sent: Thursday, January 03, 2013 9:12 AM
> To: Charles Eckel (eckelcu); 'Paul Kyzivat'
> Cc: [e-mail]
> Subject: RE: [siprec] FW: New Version Notification for draft-ram-siprec-
> callflows-02.txt
> 
> Hi Charles,
> 
> I have looked in RFC 3550 for CSRC requirements and it is as follows:
> 
> "In order to preserve the identity of the original sources
>       contributing to the mixed packet, the mixer SHOULD insert their
>       SSRC identifiers into the CSRC identifier list following the fixed
>       RTP header of the packet."
> 
> My observation is that adding CSRC identifier is "SHOULD" and not "MUST". I
> really don't know in which scenario it is permissible not to add CSRC
> identifier but it is allowed. In case you foresee that CSRC identifier MUST
> be inserted by all SRC mixer, then the normative statement in CSRC section
> of SIPREC protocol draft has to be changed as "MUST" instead of
> "RECOMMENDED".

I am not proposing to change it to a MUST. I think RECOMMENDED is appropriate, along with the explanation of why support for CSRC is important.
 
> Also still I could not see how to correlate the participant to CSRC in SRS
> as there is no linkage between CSRC in RTP & participant in SIPREC metadata
> from SRC.

Forwarding the SDES/CNAME information from the CS into the RS provides this. I also have recommended previously that we include the CNAME of a participant in the metadata. 

Cheers,
Charles

> Thanks
> Partha
> 
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]] On
> > Behalf Of Charles Eckel (eckelcu)
> > Sent: Thursday, January 03, 2013 3:46 AM
> > To: Paul Kyzivat
> > Cc: [e-mail]
> > Subject: Re: [siprec] FW: New Version Notification for draft-ram-
> > siprec-callflows-02.txt
> >
> > I expect there to be cases in which an MCU, Turret, or something
> > similar, appears to a SRC as a single UA with media from multiple
> > participants.
> > In the worst case, all the media arrives at the SRC with the same,
> > single SSRC and there is no other signaling that informs the SRC of the
> > individual participants. In such cases, the SRC cannot do anything to
> > help the SRS identify media from individual participants.
> > In a slightly improved case, the SRC does receive some information from
> > the UA regarding the set of participants. In such cases, the SRC can
> > make this information available to the SRS via metadata.
> > In an even better case, the media arrives at the SRC from the UA with a
> > separate SSRC for each participant. In such cases, the SRC can use
> > CSRCs to disambiguate media streams received by the SRS.
> >
> > It seems to me that the case you are pointing out is one in which the
> > SRC gets some information from a UA that it decides not to propagate
> > to the SRS. I agree that an SRS needs to support working with
> > incomplete information because it will be inevitable in some instances;
> > however, the case in which an SRC removes some information and one in
> > which the UA did not provide any additional information to the SRC in
> > the first place appear the same to the SRS. Therefore, I do not see a
> > need to include the "permissible" clause for the SRC. If anything, I
> > think we need to point out that SRS should be prepared to work with
> > incomplete information when it comes to identification of individual
> > participants within a mixed media stream.
> >
> > Cheers,
> > Charles
> >
> >
> >
> > > -----Original Message-----
> > > From: Paul Kyzivat [mailto:[e-mail]]
> > > Sent: Wednesday, January 02, 2013 11:24 AM
> > > To: Charles Eckel (eckelcu)
> > > Cc: [e-mail]
> > > Subject: Re: [siprec] FW: New Version Notification for draft-ram-
> > siprec-
> > > callflows-02.txt
> > >
> > > On 1/2/13 1:15 PM, Charles Eckel (eckelcu) wrote:
> > > > I'm okay with listing this as a limitation as long as the
> > limitation is stated
> > > as being due to the way media streams are constructed in the turret
> > case and
> > > not due to SRC mixing of media streams in general. For the general
> > case, no
> > > information present in the CS should be lost as a result of SRC
> > mixing for the
> > > RS.
> > >
> > > I was thinking that it is *permissible* (but not recommended) for an
> > SRC
> > > to do a very simplistic form of mixing - with just one SSRC and no
> > CSRCs
> > > - if it wishes. I think we should not exclude that, because doing so
> > may
> > > exclude some servers from being SRCs.
> > >
> > > The turret might be one instance of that.
> > >
> > > 	Thanks,
> > > 	Paul
> > >
> > > > Cheers,
> > > > Charles
> > > >
> > > >> -----Original Message-----
> > > >> From: [e-mail] [mailto:[e-mail]] On
> > > Behalf
> > > >> Of Paul Kyzivat
> > > >> Sent: Tuesday, January 01, 2013 1:56 PM
> > > >> To: [e-mail]
> > > >> Subject: Re: [siprec] FW: New Version Notification for draft-ram-
> > siprec-
> > > >> callflows-02.txt
> > > >>
> > > >> 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:internet-
> > [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
> > > >>>
> > > >>
> > > >> _______________________________________________
> > > >> siprec mailing list
> > > >> [e-mail]
> > > >> https://www.ietf.org/mailman/listinfo/siprec
> > > >
> >
> > _______________________________________________
> > siprec mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/siprec