Re: [siprec] Review Request for draft-ram-siprec-metadata-format-01

Please see single comment inline.

> -----Original Message-----
> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On
Behalf Of Elwell, John
> Sent: Tuesday, March 15, 2011 6:56 AM
> To: Paul Kyzivat (pkyzivat)
> Cc: siprec@ietf.org
> Subject: Re: [siprec] Review Request for
draft-ram-siprec-metadata-format-01
> 
> 
> 
> 
> > -----Original Message-----
> > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
> > Sent: 15 March 2011 13:03
> > To: Elwell, John
> > Cc: siprec@ietf.org
> > Subject: Re: [siprec] Review Request for
> > draft-ram-siprec-metadata-format-01
> >
> > On 3/15/2011 7:22 AM, Elwell, John wrote:
> >
> > >>> 2. We perhaps need to think about mixed RS media streams,
> > >> i.e., where several CS media streams have been mixed to
> > >> produce a single RS media stream. In this case, the several
> > >> Media Stream objects would all point to the same SDP label, I
> > >> guess. This then brings into question the mode element (type
> > >> streamMode) - why is this needed? The fact that several Media
> > >> Stream objects (stream elements) point to the same label
> > >> would imply there has been mixing, so the mode element seems
> > >> to be redundant.
> > >>
> > >> My thinking is that situation is modeled as a single media
> > >> stream with
> > >> multiple participants.
> > > [JRE] I was confused by section 4.5 of the metadata model
> > draft. It does indeed seem to say that it represents an RS
> > media stream:
> > > "A Media Stream block shall have properties of media as
> > seen by SRC and sent to SRS."
> > > And hence your interpretation above would seem reasonable.
> > On the other hand, in 4.5.2 it says:
> > > "A Media Stream SHALL be associated with Participant and CS."
> > > This misled me. Also in 4.5.1:
> > > "Codec params - represents codec parameters of the CS media"
> > > This also seemed to imply the Media Stream object relates
> > to a CS media stream.
> > > Perhaps some clarification is needed in the Metadata draft.
> > > Anyway, assuming we go with your interpretation, I suppose
> > what we end up with is that if streams are mixed (whether
> > this be at an MCU, say, or just part of the SRC in order to
> > send the streams to the SRS), the net result will be
> > modelling as a single stream in the metadata. Is this a
> > common understanding?
> >
> > You may have a point here - that things are somewhat ambiguous.
> >
> > If we have two distinct media streams in the CS, and they are mixed
> > together by the SRC before sending to the SRS, then they could be
> > treated different ways:
> >
> > - The SRC could report this as a single media stream with multiple
> > participants. But then it would have to report its metadata as if it
> > were a single stream from a mixer.
> >
> > - The SRC could report it as multiple media streams from a metadata
> > perspective, but map them all onto the same RS media stream.
> > (This is a
> > possibility I had never considered/recognized.)
> >
> > Is there a desire to support both? If so, the metamodel and
mechanism
> > will probably need some tweaking.
> [JRE] Consider:
> "REQ-009: The mechanism MUST support the ability for an SRC to
>    deliver mixed audio streams from different parties of a given
>    Communication Session to an SRS."
> One particular case I believe this covers is the simple 2-party call,
where there are two media
> streams, one from A to B and the other from B to A. The SRC could mix
the two together into a single
> stream to the SRS. Certainly useful for bandwidth constrained
environments, but not so friendly
> towards speech analytics.
> 
> John (as individual)

Once the stream is mixed meaning all packets have the same SSRC and
CSRC, I think there is no point in trying to represent it as anything
other than a single stream. If the metadata can indicate all the
individual participants in the mixed stream, that would be great, but I
doubt you will get this in all cases.
If it is a single RTP stream with multiple identifiable media streams
muxed together, then it would be good to model as independent streams.
In this case the different streams could be uniquely identified by a
SSRC or CSRC. 

Cheers,
Charles

> 
> >
> > 	Thanks,
> > 	Paul
> >
> _______________________________________________
> siprec mailing list
> siprec@ietf.org
> https://www.ietf.org/mailman/listinfo/siprec