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

From: "Parthasarathi R" <[email-masked]>
Date: Tue, 1 Jan 2013 21:27:04 +0530

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.

Hope Turret case solution is clarified to you.

Thanks
Partha 

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

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 01 Jan 2013 16:55:50 -0500

> solve this issue, Please let us know.

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

	Thanks,
	Paul

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Wed, 2 Jan 2013 18:15:44 +0000

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.

Cheers,
Charles

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Paul Kyzivat
> Sent: Tuesday, January 01, 2013 1:56 PM
> To: [email-masked]
> Subject: Re: [siprec] FW: New Version Notification for draft-ram-siprec-
> callflows-02.txt
>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 02 Jan 2013 14:23:44 -0500

> 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…

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

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Wed, 2 Jan 2013 22:15:46 +0000

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

> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Wednesday, January 02, 2013 11:24 AM
> To: Charles Eckel (eckelcu)
> Cc: [email-masked]
> > 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.
>

---

From: "Parthasarathi R" <[email-masked]>
Date: Thu, 3 Jan 2013 22:42:14 +0530

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". 

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.

Thanks
Partha

> Behalf Of Charles Eckel (eckelcu)
> Sent: Thursday, January 03, 2013 3:46 AM
> To: Paul Kyzivat
> Cc: [email-masked]
> 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
> 
> 
> 
> > >>> 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
> > >>> contributor of the mixed media". We have tried to use CSRC
> earlier and
> > not
> > >>>>>> 1) Incorporating RS SIP messages with metadata XML messages
> for
> > all
> > >>>>>> callflow

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Thu, 3 Jan 2013 17:45:56 +0000

Hi Partha,

Please see inline.

> Sent: Thursday, January 03, 2013 9:12 AM
> To: Charles Eckel (eckelcu); 'Paul Kyzivat'
> Cc: [email-masked]
> Subject: RE: [siprec] FW: New Version Notification for draft-ram-siprec-
> callflows-02.txt
> 
> Hi Charles,
> 

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.
 
> as there is no linkage between CSRC in RTP & participant in SIPREC metadata

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