Subject: [clue] Requirements & use cases ( was Re: Multiple Streams - RTP muxing?

From: Mary Barnes <[email-masked]>
Date: Tue, 1 Feb 2011 17:02:31 -0600

Hi Folks,

John has an excellent point wrt requirements. It will be extremely helpful
to start defining the requirements which are a WG deliverable.  Allyn is
working on those right now and will submit an individual draft within the
next few weeks. In the meantime if you have specific requirements in mind,
please send text directly to Allyn or post on the mailing list. Note, that I
changed the title of this thread in case folks reply directly.

In addition, it would be really good to get WG feedback on the use cases per
Allyn's recent email:
http://www.ietf.org/mail-archive/web/clue/current/msg00074.html
Please reply separately to that thread.

As John notes, this isn't to say folks shouldn't be considering solutions,
it's just that we also need to make sure that there is sufficient focus and
effort into the first two WG deliverables.  If we don't get those completed
in a timely manner, we won't get to defining the solution.

Thanks,
Mary.
CLUE WG co-chair

On Tue, Feb 1, 2011 at 9:34 AM, Elwell, John <
[email-masked]> wrote:

>
>
> > -----Original Message-----
> > From: Stephen Botzko [mailto:[email-masked]]
> > Sent: 01 February 2011 11:56
> > To: Elwell, John
> > Cc: Charles Eckel (eckelcu); Magnus Westerlund; CLUE
> > Subject: Re: [clue] Multiple Streams - RTP muxing?
> >
> > The use cases and the problem statement drafts were not
> > intended to be requirements documents.  I agree that
> > scalability needs to be discussed, and that use cases for
> > large scale conferences are needed.
> [JRE] That's what I thought. So perhaps we do need to start assembling
> requirements, although I am not suggesting that should prevent us having
> these discussions on solution.
>
> >
> > Existing telepresence systems I am aware of receive/decode
> > one video stream per display.
> >
> > However, it is quite practical to send one video stream per
> > rendered image (instead of using video transcoding),
> > especially if the sender either simulcasts multiple
> > resolutions or uses a layered video codec like SVC.  This can
> > greatly increase the number of streams that are received at
> > each endpoint, and also makes the received stream mix much
> > more dynamic. One benefit is that transcoding/transrating
> > delay is at least reduced and in many cases eliminated.
> [JRE] You mention the mix being much more dynamic. So if we were to go for
> multiplexing at the transport level, presumably there is then the question
> of whether changes are negotiated at the RTP level (likely to be quicker) or
> at the SDP level.
>
> John
>
>
> >
> > Both approaches were listed in the problem statement draft
> > last year (in the multipoint section).  Personally I favor a
> > solution that accommodates both.
> >
> > Stephen Botzko
> >
> >
> > On Tue, Feb 1, 2011 at 6:30 AM, Elwell, John
> > <[email-masked]> wrote:
> >
> >
> >       I really think we should have some sort of
> > understanding on scalability requirements here. I don't think
> > this is covered in either of the two drafts to date, but I
> > may have missed it.
> >
> >       John
> >
> >
> >       > -----Original Message-----
> >       > From: [email-masked] [mailto:[email-masked]] On
> >
> >       > Behalf Of Charles Eckel (eckelcu)
> >
> >       > Sent: 31 January 2011 15:50
> >       > To: Stephen Botzko; Magnus Westerlund
> >       > Cc: CLUE
> >       > Subject: Re: [clue] Multiple Streams - RTP muxing?
> >       >
> >       > I was thinking (2) as well; however, one concern I have is
> >       > scalability. As the number of screens increases from 3 or so
> >       > to say 10 or 100, does the set of pros and cons change. I
> >       > would hate to have 100 m-lines, but 100 streams each with its
> >       > own SSRC multiplexed in a single RTP session may be
> >       > programmatic as well.
> >       > I am hoping those more familiar with the complexities and
> >       > limitations of RTP stream processing can chime in. Will we
> >       > have no choice but to break it into multiple RTP sessions?
> >       >
> >       > Thanks,
> >       > Charles
> >       >
> >       > > -----Original Message-----
> >       > > From: [email-masked] [mailto:[email-masked]]
> >       > On Behalf Of Stephen Botzko
> >       > > Sent: Monday, January 31, 2011 4:52 AM
> >       > > To: Magnus Westerlund
> >       > > Cc: CLUE
> >       > > Subject: Re: [clue] Multiple Streams - RTP muxing?
> >       > >
> >       > > Hi
> >       > > >>>
> >       > > 1. One RTP session, with one SSRC that contains the
> >       > encoding of multiple
> >       > > different original flows through either
> > transcoding, or a new
> >       > > multiplexing mechanism?
> >       > >
> >       > > 2. One RTP session, with one SSRC per original video stream.
> >       > > >>>
> >       > >
> >       > > I was thinking (2).  (one session for audio and one for
> >       > video).  I'd be open to (1) if it did not
> >       > > require transcoding.  However, I am not convinced a totally
> >       > new mechanism is needed.
> >       > >
> >       > > Though it hasn't come up yet, I was also wondering about
> >       > having all video and audio streams from the
> >       > > same CLUE endpoint use the same clock offset, in order to
> >       > simplify lip-sync management with multiple
> >       > > audio and multiple video streams.  Not sure about that, but
> >       > I do see a lot of complexity in
> >       > > determining the proper delays.
> >       > >
> >       > > Stephen Botzko
> >       > >
> >       > >
> >       > >
> >       > > On Mon, Jan 31, 2011 at 7:41 AM, Magnus Westerlund
> >       > <[email-masked]> wrote:
> >       > >
> >       > >
> >       > >     Hi,
> >       > >
> >       > >     (AS AVTCore Chair)
> >       > >
> >       > >     I want to inject into this discussion a request to be a
> >       > bit more clear
> >       > >     on what people are considering. Because RTP has several
> >       > multiplexing
> >       > >     points and some may even want to go furhter than the
> >       > existing ones. So
> >       > >     can everyone please clarify what they are talking about.
> >       > >
> >       > >     Please keep in mind that RTP has certain point of where
> >       > things are
> >       > >     intended to separated. This also affects the
> >       > possibility to use existing
> >       > >     RTP tools.
> >       > >
> >       > >     So a primer in RTP terminology:
> >       > >
> >       > >     RTP Session: One SSRC space, normally determined based
> >       > on transport
> >       > >     level ports. Each RTP session normally servers one
> >       > media type and one
> >       > >     purpose. Using different media types (audio and video)
> >       > will creates
> >       > >     issues for some tools and SDP based signalling.
> >       > >
> >       > >     SSRC, a single media stream source. Multiple SSRC can
> >       > be used in the
> >       > >     same RTP session.
> >       > >
> >       > >     RTP payload type, identifies the encoding of the RTP
> >       > payload. Thus
> >       > >     possibly identifying video screen sizes etc.
> >       > >
> >       > >     So I will start with asking Peter to clarify the below
> >       > statement:
> >       > >
> >       > >     Peter Musgrave skrev 2011-01-29 08:51:
> >       > >
> >       > >     >
> >       > >     > I think the notion of a single, multiplexed video
> >       > stream for a TP endpoint makes a lot of
> >       > > sense in the context of CLUE.
> >       > >
> >       > >
> >       > >     I can interpret this as meaning either of:
> >       > >
> >       > >     1. One RTP session, with one SSRC that contains the
> >       > encoding of multiple
> >       > >     different original flows through either
> > transcoding, or a new
> >       > >     multiplexing mechanism?
> >       > >
> >       > >     2. One RTP session, with one SSRC per original
> > video stream.
> >       > >
> >       > >     So please be clear on what you are discussing and
> >       > suggesting here.
> >       > >
> >       > >     Cheers
> >       > >
> >       > >     Magnus Westerlund
> >       > >
> >       > >
> >       >
> > ----------------------------------------------------------------------
> >       > >     Multimedia Technologies, Ericsson Research EAB/TVM
> >       > >
> >       >
> > ----------------------------------------------------------------------
> >       > >     Ericsson AB                | Phone  +46 10 7148287
> >       > >     Färögatan 6                | Mobile +46 73 0949079
> >       > >     SE-164 80 Stockholm, Sweden| mailto:
> >       > [email-masked]
> >       > >
> >       >
> > ----------------------------------------------------------------------
> >       > >
> >       > >     _______________________________________________
> >       > >     clue mailing list
> >       > >     [email-masked]
> >       > >     https://www.ietf.org/mailman/listinfo/clue
> >       > >
> >       > >
> >       >
> >       > _______________________________________________
> >       > clue mailing list
> >       > [email-masked]
> >       > https://www.ietf.org/mailman/listinfo/clue
> >       >
> >
> >
> >
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue
>