From john.elwell@siemens-enterprise.com Tue Feb 1 03:27:38 2011 Return-Path: X-Original-To: clue@core3.amsl.com Delivered-To: clue@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 640393A6914 for ; Tue, 1 Feb 2011 03:27:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.535 X-Spam-Level: X-Spam-Status: No, score=-102.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KRgvW4Kul-wg for ; Tue, 1 Feb 2011 03:27:37 -0800 (PST) Received: from ms03.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 0C61F3A68F3 for ; Tue, 1 Feb 2011 03:27:36 -0800 (PST) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms03.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-3216461; Tue, 1 Feb 2011 12:30:42 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id 2BD0923F0294; Tue, 1 Feb 2011 12:30:42 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Tue, 1 Feb 2011 12:30:41 +0100 From: "Elwell, John" To: "Charles Eckel (eckelcu)" , Stephen Botzko , Magnus Westerlund Date: Tue, 1 Feb 2011 12:30:41 +0100 Thread-Topic: [clue] Multiple Streams - RTP muxing? Thread-Index: AcvBRdF7z9AtjXYmSJKqHPHgbzDXrwAF36WAACluFsA= Message-ID: References: <9EEB6465-626A-43B9-A653-A9B67FC01E80@magorcorp.com><4D46ADFD.8010506@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: CLUE Subject: Re: [clue] Multiple Streams - RTP muxing? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 11:27:38 -0000 I really think we should have some sort of understanding on scalability req= uirements here. I don't think this is covered in either of the two drafts t= o date, but I may have missed it. John=20 > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On=20 > 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? >=20 > I was thinking (2) as well; however, one concern I have is=20 > scalability. As the number of screens increases from 3 or so=20 > to say 10 or 100, does the set of pros and cons change. I=20 > would hate to have 100 m-lines, but 100 streams each with its=20 > own SSRC multiplexed in a single RTP session may be=20 > programmatic as well. > I am hoping those more familiar with the complexities and=20 > limitations of RTP stream processing can chime in. Will we=20 > have no choice but to break it into multiple RTP sessions? >=20 > Thanks, > Charles >=20 > > -----Original Message----- > > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org]=20 > 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? > >=20 > > Hi > > >>> > > 1. One RTP session, with one SSRC that contains the=20 > encoding of multiple > > different original flows through either transcoding, or a new > > multiplexing mechanism? > >=20 > > 2. One RTP session, with one SSRC per original video stream. > > >>> > >=20 > > I was thinking (2). (one session for audio and one for=20 > video). I'd be open to (1) if it did not > > require transcoding. However, I am not convinced a totally=20 > new mechanism is needed. > >=20 > > Though it hasn't come up yet, I was also wondering about=20 > having all video and audio streams from the > > same CLUE endpoint use the same clock offset, in order to=20 > simplify lip-sync management with multiple > > audio and multiple video streams. Not sure about that, but=20 > I do see a lot of complexity in > > determining the proper delays. > >=20 > > Stephen Botzko > >=20 > >=20 > >=20 > > On Mon, Jan 31, 2011 at 7:41 AM, Magnus Westerlund=20 > wrote: > >=20 > >=20 > > Hi, > >=20 > > (AS AVTCore Chair) > >=20 > > I want to inject into this discussion a request to be a=20 > bit more clear > > on what people are considering. Because RTP has several=20 > multiplexing > > points and some may even want to go furhter than the=20 > existing ones. So > > can everyone please clarify what they are talking about. > >=20 > > Please keep in mind that RTP has certain point of where=20 > things are > > intended to separated. This also affects the=20 > possibility to use existing > > RTP tools. > >=20 > > So a primer in RTP terminology: > >=20 > > RTP Session: One SSRC space, normally determined based=20 > on transport > > level ports. Each RTP session normally servers one=20 > media type and one > > purpose. Using different media types (audio and video)=20 > will creates > > issues for some tools and SDP based signalling. > >=20 > > SSRC, a single media stream source. Multiple SSRC can=20 > be used in the > > same RTP session. > >=20 > > RTP payload type, identifies the encoding of the RTP=20 > payload. Thus > > possibly identifying video screen sizes etc. > >=20 > > So I will start with asking Peter to clarify the below=20 > statement: > >=20 > > Peter Musgrave skrev 2011-01-29 08:51: > >=20 > > > > > > I think the notion of a single, multiplexed video=20 > stream for a TP endpoint makes a lot of > > sense in the context of CLUE. > >=20 > >=20 > > I can interpret this as meaning either of: > >=20 > > 1. One RTP session, with one SSRC that contains the=20 > encoding of multiple > > different original flows through either transcoding, or a new > > multiplexing mechanism? > >=20 > > 2. One RTP session, with one SSRC per original video stream. > >=20 > > So please be clear on what you are discussing and=20 > suggesting here. > >=20 > > Cheers > >=20 > > Magnus Westerlund > >=20 > > =09 > ---------------------------------------------------------------------- > > Multimedia Technologies, Ericsson Research EAB/TVM > > =09 > ---------------------------------------------------------------------- > > Ericsson AB | Phone +46 10 7148287 > > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > > SE-164 80 Stockholm, Sweden| mailto:=20 > magnus.westerlund@ericsson.com > > =09 > ---------------------------------------------------------------------- > >=20 > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue > >=20 > >=20 >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > = From stephen.botzko@gmail.com Tue Feb 1 03:52:27 2011 Return-Path: X-Original-To: clue@core3.amsl.com Delivered-To: clue@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 663EC3A68ED for ; Tue, 1 Feb 2011 03:52:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.337 X-Spam-Level: X-Spam-Status: No, score=-3.337 tagged_above=-999 required=5 tests=[AWL=0.261, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vsf4BF1m2zr2 for ; Tue, 1 Feb 2011 03:52:25 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 894CB3A6CC0 for ; Tue, 1 Feb 2011 03:52:25 -0800 (PST) Received: by qwi2 with SMTP id 2so6996876qwi.31 for ; Tue, 01 Feb 2011 03:55:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=xy3U88XGQonucHGHHquDwNRSRQ14sHk7/l7N/uSRTsI=; b=MU8+pMWQdWZNv3sahdHeyhm72PugI8Xjym1xy+CHyUwhkpKI+jXQBCoTzVMsRe7KMj iQ8mMeh1V1DxFz+jVUGK7+AdBDcwYc4jh7HA8Fd1rLs4PEKigJWAkyQRfaEGCdffEzym 49Vpt9P5re6ejnVFjwtLrbBa9l6xl44AVeMt4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=CPaTz8/W0KPecKn0vUFOBN4J1vs1Mk1y/v0aqH4HIbYE8qGAGOR8DRnNgpOHPQU3cu DUkLQF97IKe3Z6VpX5L6NuZJhpFXAKZSm7Ma7tNldVmlC2Gl+QgnztbBGNGyP9mcEhVe 6uEhoq/L9+D0NYO1XgwKnoO9vCSeG3jmvovkM= MIME-Version: 1.0 Received: by 10.224.20.4 with SMTP id d4mr834629qab.345.1296561341939; Tue, 01 Feb 2011 03:55:41 -0800 (PST) Received: by 10.220.128.30 with HTTP; Tue, 1 Feb 2011 03:55:41 -0800 (PST) In-Reply-To: References: <9EEB6465-626A-43B9-A653-A9B67FC01E80@magorcorp.com> <4D46ADFD.8010506@ericsson.com> Date: Tue, 1 Feb 2011 06:55:41 -0500 Message-ID: From: Stephen Botzko To: "Elwell, John" Content-Type: multipart/alternative; boundary=0015175cda2c3741c2049b373688 Cc: CLUE Subject: Re: [clue] Multiple Streams - RTP muxing? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 11:52:27 -0000 --0015175cda2c3741c2049b373688 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The use cases and the problem statement drafts were not intended to be requirements documents. I agree that scalability needs to be discussed, an= d that use cases for large scale conferences are needed. 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. Both approaches were listed in the problem statement draft last year (in th= e multipoint section). Personally I favor a solution that accommodates both. Stephen Botzko On Tue, Feb 1, 2011 at 6:30 AM, Elwell, John < john.elwell@siemens-enterprise.com> 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 dra= fts > to date, but I may have missed it. > > John > > > -----Original Message----- > > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] 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: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] > > 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 > > 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=E4r=F6gatan 6 | Mobile +46 73 0949079 > > > SE-164 80 Stockholm, Sweden| mailto: > > magnus.westerlund@ericsson.com > > > > > ---------------------------------------------------------------------- > > > > > > _______________________________________________ > > > clue mailing list > > > clue@ietf.org > > > https://www.ietf.org/mailman/listinfo/clue > > > > > > > > > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue > > > --0015175cda2c3741c2049b373688 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The use cases and the problem statement drafts were not intended to be requ= irements documents.=A0 I agree that scalability needs to be discussed, and = that use cases for large scale conferences are needed.

Existing tele= presence systems I am aware of receive/decode one video stream per display.= =A0=A0

However, it is quite practical to send one video stream per rendered im= age (instead of using video transcoding), especially if the sender either s= imulcasts multiple resolutions or uses a layered video codec like SVC.=A0 T= his can greatly increase the number of streams that are received at each en= dpoint, and also makes the received stream mix much more dynamic. One benef= it is that transcoding/transrating delay is at least reduced and in many ca= ses eliminated.

Both approaches were listed in the problem statement draft last year (i= n the multipoint section).=A0 Personally I favor a solution that accommodat= es both.

Stephen Botzko

On Tue, Fe= b 1, 2011 at 6:30 AM, Elwell, John <john.elwell@siemens-enterprise.com&= gt; 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: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] 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: clue-bounces@ietf.= org [mailto:clue-bounces@ietf.= org]
> 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). =A0(one session for audio and one for
> video). =A0I'd be open to (1) if it did not
> > require transcoding. =A0However, 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. =A0Not 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
> <magnus.westerlun= d@ericsson.com> wrote:
> >
> >
> > =A0 =A0 Hi,
> >
> > =A0 =A0 (AS AVTCore Chair)
> >
> > =A0 =A0 I want to inject into this discussion a request to be a > bit more clear
> > =A0 =A0 on what people are considering. Because RTP has several > multiplexing
> > =A0 =A0 points and some may even want to go furhter than the
> existing ones. So
> > =A0 =A0 can everyone please clarify what they are talking about.<= br> > >
> > =A0 =A0 Please keep in mind that RTP has certain point of where > things are
> > =A0 =A0 intended to separated. This also affects the
> possibility to use existing
> > =A0 =A0 RTP tools.
> >
> > =A0 =A0 So a primer in RTP terminology:
> >
> > =A0 =A0 RTP Session: One SSRC space, normally determined based > on transport
> > =A0 =A0 level ports. Each RTP session normally servers one
> media type and one
> > =A0 =A0 purpose. Using different media types (audio and video) > will creates
> > =A0 =A0 issues for some tools and SDP based signalling.
> >
> > =A0 =A0 SSRC, a single media stream source. Multiple SSRC can
> be used in the
> > =A0 =A0 same RTP session.
> >
> > =A0 =A0 RTP payload type, identifies the encoding of the RTP
> payload. Thus
> > =A0 =A0 possibly identifying video screen sizes etc.
> >
> > =A0 =A0 So I will start with asking Peter to clarify the below > statement:
> >
> > =A0 =A0 Peter Musgrave skrev 2011-01-29 08:51:
> >
> > =A0 =A0 >
> > =A0 =A0 > I think the notion of a single, multiplexed video > stream for a TP endpoint makes a lot of
> > sense in the context of CLUE.
> >
> >
> > =A0 =A0 I can interpret this as meaning either of:
> >
> > =A0 =A0 1. One RTP session, with one SSRC that contains the
> encoding of multiple
> > =A0 =A0 different original flows through either transcoding, or a= new
> > =A0 =A0 multiplexing mechanism?
> >
> > =A0 =A0 2. One RTP session, with one SSRC per original video stre= am.
> >
> > =A0 =A0 So please be clear on what you are discussing and
> suggesting here.
> >
> > =A0 =A0 Cheers
> >
> > =A0 =A0 Magnus Westerlund
> >
> >
> ----------------------------------------------------------------------=
> > =A0 =A0 Multimedia Technologies, Ericsson Research EAB/TVM
> >
> ----------------------------------------------------------------------=
> > =A0 =A0 Ericsson AB =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Phone =A0+46= 10 7148287
> > =A0 =A0 F=E4r=F6gatan 6 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Mobile += 46 73 0949079
> > =A0 =A0 SE-164 80 Stockholm, Sweden| mailto:
> magnus.westerlund@er= icsson.com
> >
> ----------------------------------------------------------------------=
> >
> > =A0 =A0 _______________________________________________
> > =A0 =A0 clue mailing list
> > =A0 =A0 clue@ietf.org
> > =A0 =A0 https://www.ietf.org/mailman/listinfo/clue
> >
> >
>
> _______________________________________________
> clue mailing list
> clue@ietf.org
> https://www.ietf.org/mailman/listinfo/clue
>

--0015175cda2c3741c2049b373688-- From magnus.westerlund@ericsson.com Tue Feb 1 04:48:26 2011 Return-Path: X-Original-To: clue@core3.amsl.com Delivered-To: clue@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BA0A3A6B2B for ; Tue, 1 Feb 2011 04:48:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.489 X-Spam-Level: X-Spam-Status: No, score=-106.489 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O-NWnMyfIe48 for ; Tue, 1 Feb 2011 04:48:25 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 18A7F3A6ABD for ; Tue, 1 Feb 2011 04:48:24 -0800 (PST) X-AuditID: c1b4fb39-b7cfbae000005c8e-b5-4d4801dd4d2f Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id A6.EB.23694.DD1084D4; Tue, 1 Feb 2011 13:51:41 +0100 (CET) Received: from [147.214.183.170] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.2.234.1; Tue, 1 Feb 2011 13:51:02 +0100 Message-ID: <4D4801B6.7020905@ericsson.com> Date: Tue, 1 Feb 2011 13:51:02 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; sv-SE; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: aravind sethuraman References: <9EEB6465-626A-43B9-A653-A9B67FC01E80@magorcorp.com> <4D46ADFD.8010506@ericsson.com> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: CLUE Subject: Re: [clue] Multiple Streams - RTP muxing? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 12:48:26 -0000 aravind sethuraman skrev 2011-01-31 20:03: > Hi all, > if we chose a single RTP session for ALL video and AUDIO, how will we > signal which SSRC conforms to which screen etc? Not via RTCP like TIP does. I just want to point out that signalling this with a single m= line in SDP is impossible. As the general media type is part of the m= line one can't have both RTP payload types of both audio and video type in the same m= line. When it comes to RTP RFC 3550 discusses this type of multiplexing and has the following to say on the issue (from section 5.2 of RFC 3550): For efficient protocol processing, the number of multiplexing points should be minimized, as described in the integrated layer processing design principle [10]. In RTP, multiplexing is provided by the destination transport address (network address and port number) which is different for each RTP session. For example, in a teleconference composed of audio and video media encoded separately, each medium SHOULD be carried in a separate RTP session with its own destination transport address. Separate audio and video streams SHOULD NOT be carried in a single RTP session and demultiplexed based on the payload type or SSRC fields. Interleaving packets with different RTP media types but using the same SSRC would introduce several problems: 1. If, say, two audio streams shared the same RTP session and the same SSRC value, and one were to change encodings and thus acquire a different RTP payload type, there would be no general way of identifying which stream had changed encodings. 2. An SSRC is defined to identify a single timing and sequence number space. Interleaving multiple payload types would require different timing spaces if the media clock rates differ and would require different sequence number spaces to tell which payload type suffered packet loss. 3. The RTCP sender and receiver reports (see Section 6.4) can only describe one timing and sequence number space per SSRC and do not carry a payload type field. 4. An RTP mixer would not be able to combine interleaved streams of incompatible media into one stream. 5. Carrying multiple media in one RTP session precludes: the use of different network paths or network resource allocations if appropriate; reception of a subset of the media if desired, for example just audio if video would exceed the available bandwidth; and receiver implementations that use separate processes for the different media, whereas using separate RTP sessions permits either single- or multiple-process implementations. Using a different SSRC for each medium but sending them in the same RTP session would avoid the first three problems but not the last two. On the other hand, multiplexing multiple related sources of the same medium in one RTP session using different SSRC values is the norm for multicast sessions. The problems listed above don't apply: an RTP mixer can combine multiple audio sources, for example, and the same treatment is applicable for all of them. It may also be appropriate to multiplex streams of the same medium using different SSRC values in other scenarios where the last two problems do not apply. As can be seen if one puts audio and video in the same RTP session but with unique SSRCs for each stream one still do need to take care. Issue 4, can be solved by explicit signalling, but makes the solution more fragile in cases with dynamic memberships. If you don't have the inforamtion about the stream mixing decisions are more difficult. Issue 5, I think becomes important as soon as we talk about a heterogeneous set of session participants. A case that are part of the charter to consider and solve. In general I think this discussion should up level for a while. Lets start discussing the general architecture and use cases and what requirements that puts on the different nodes in the architecture. Then we can return to this and see what requirements we have and how they matches the capabilities of the protocols we intended to solve it with. 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: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From stephen.botzko@gmail.com Tue Feb 1 05:32:09 2011 Return-Path: X-Original-To: clue@core3.amsl.com Delivered-To: clue@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E1553A7230 for ; Tue, 1 Feb 2011 05:32:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.351 X-Spam-Level: X-Spam-Status: No, score=-3.351 tagged_above=-999 required=5 tests=[AWL=0.247, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CXzOIRFk2swK for ; Tue, 1 Feb 2011 05:32:07 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 3DB953A7206 for ; Tue, 1 Feb 2011 05:31:01 -0800 (PST) Received: by qwi2 with SMTP id 2so7106606qwi.31 for ; Tue, 01 Feb 2011 05:34:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=gAefFtI4KqM/fhUZ1DZBzokiQW56o9a1AdYOXloDl/M=; b=UKTs0ZGmcvR0N5vTqXq+hHKcGtmWKCPSnNoGNlczajOmpO21oCU3CqYaOfQLgD2+ah KvODmAud1BvhMX58lIrb/6Tiq5jfj2sfBCDPRiJlUclIWBSCkWuRUoxXl+uY/WKNcj/D ZpVs4k+0x9BhxryzD8xX4g7G1Im2jdIyFSDd4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=JgnonuZCHIcaeO+9nTQRmynhXe1iC7O45YO6g9J8FClm5zf1LGii3nU8J8eQCfnxf3 y33Cx6eWjWL1EtTCEzHpNH2PxK8J+c+LHTSR3rF0G9nJzjfvL/Hots7JEkOURAkzptQA 1Uo1+Tam4utJ/r9imaOf3Q8YSK2jUIq7QhCgo= MIME-Version: 1.0 Received: by 10.224.28.196 with SMTP id n4mr7537705qac.295.1296567257948; Tue, 01 Feb 2011 05:34:17 -0800 (PST) Received: by 10.220.128.30 with HTTP; Tue, 1 Feb 2011 05:34:17 -0800 (PST) In-Reply-To: <4D4801B6.7020905@ericsson.com> References: <9EEB6465-626A-43B9-A653-A9B67FC01E80@magorcorp.com> <4D46ADFD.8010506@ericsson.com> <4D4801B6.7020905@ericsson.com> Date: Tue, 1 Feb 2011 08:34:17 -0500 Message-ID: From: Stephen Botzko To: Magnus Westerlund Content-Type: multipart/alternative; boundary=0015175ce0ccd6629b049b389663 Cc: CLUE Subject: Re: [clue] Multiple Streams - RTP muxing? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 13:32:09 -0000 --0015175ce0ccd6629b049b389663 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable >>> As the general media type is part of the m=3D line one can't have both RTP payload types of both audio and video type in the same m=3D line. >>>There might be some confusion here, I didn't hear anyone propose multiplexing both audio and video in the same session. I believe the multiplex idea is to have two sessions, one for audio and one for video. This is what existing video systems that employ multiplexing do. >>> In general I think this discussion should up level for a while. >>> Probably a good idea. This will come back, there are a lot of folks who build telepresence systems who favor SSRC multiplexing. Stephen Botzko On Tue, Feb 1, 2011 at 7:51 AM, Magnus Westerlund < magnus.westerlund@ericsson.com> wrote: > aravind sethuraman skrev 2011-01-31 20:03: > > Hi all, > > if we chose a single RTP session for ALL video and AUDIO, how will we > > signal which SSRC conforms to which screen etc? Not via RTCP like TIP > does. > > I just want to point out that signalling this with a single m=3D line in > SDP is impossible. As the general media type is part of the m=3D line one > can't have both RTP payload types of both audio and video type in the > same m=3D line. > > When it comes to RTP RFC 3550 discusses this type of multiplexing and > has the following to say on the issue (from section 5.2 of RFC 3550): > > For efficient protocol processing, the number of multiplexing points > should be minimized, as described in the integrated layer processing > design principle [10]. In RTP, multiplexing is provided by the > destination transport address (network address and port number) which > is different for each RTP session. For example, in a teleconference > composed of audio and video media encoded separately, each medium > SHOULD be carried in a separate RTP session with its own destination > transport address. > > Separate audio and video streams SHOULD NOT be carried in a single > RTP session and demultiplexed based on the payload type or SSRC > fields. Interleaving packets with different RTP media types but > using the same SSRC would introduce several problems: > > 1. If, say, two audio streams shared the same RTP session and the > same SSRC value, and one were to change encodings and thus acquire > a different RTP payload type, there would be no general way of > identifying which stream had changed encodings. > > 2. An SSRC is defined to identify a single timing and sequence number > space. Interleaving multiple payload types would require > different timing spaces if the media clock rates differ and would > require different sequence number spaces to tell which payload > type suffered packet loss. > > 3. The RTCP sender and receiver reports (see Section 6.4) can only > describe one timing and sequence number space per SSRC and do not > carry a payload type field. > > 4. An RTP mixer would not be able to combine interleaved streams of > incompatible media into one stream. > > 5. Carrying multiple media in one RTP session precludes: the use of > different network paths or network resource allocations if > appropriate; reception of a subset of the media if desired, for > example just audio if video would exceed the available bandwidth; > and receiver implementations that use separate processes for the > different media, whereas using separate RTP sessions permits > either single- or multiple-process implementations. > > Using a different SSRC for each medium but sending them in the same > RTP session would avoid the first three problems but not the last > two. > > On the other hand, multiplexing multiple related sources of the same > medium in one RTP session using different SSRC values is the norm for > multicast sessions. The problems listed above don't apply: an RTP > mixer can combine multiple audio sources, for example, and the same > treatment is applicable for all of them. It may also be appropriate > to multiplex streams of the same medium using different SSRC values > in other scenarios where the last two problems do not apply. > > > As can be seen if one puts audio and video in the same RTP session but > with unique SSRCs for each stream one still do need to take care. > > Issue 4, can be solved by explicit signalling, but makes the solution > more fragile in cases with dynamic memberships. If you don't have the > inforamtion about the stream mixing decisions are more difficult. > > Issue 5, I think becomes important as soon as we talk about a > heterogeneous set of session participants. A case that are part of the > charter to consider and solve. > > In general I think this discussion should up level for a while. Lets > start discussing the general architecture and use cases and what > requirements that puts on the different nodes in the architecture. Then > we can return to this and see what requirements we have and how they > matches the capabilities of the protocols we intended to solve it with. > > Cheers > > Magnus Westerlund > > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > --0015175ce0ccd6629b049b389663 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable >>>
As the general media type is part of the m=3D line one
can't have both RTP payload types of both audio and video type in the same m=3D line.
>>>There might be some confusion here, I didn&#= 39;t hear anyone propose multiplexing both audio and video in the same sess= ion.=A0 I believe the multiplex idea is to have two sessions, one for audio= and one for video.=A0 This is what existing video systems that employ mult= iplexing do.

>>>
In general I think this discussion should up level for = a while.
>>>
Probably a good idea.=A0 This will come back, t= here are a lot of folks who build telepresence systems who favor SSRC multi= plexing.

Stephen Botzko

On Tue, Feb 1, 2011 at= 7:51 AM, Magnus Westerlund <magnus.westerlund@ericsson.com> wrot= e:
aravind sethurama= n skrev 2011-01-31 20:03:
> Hi all,
> if we chose a single RTP session for ALL video and AUDIO, how will we<= br> > signal which SSRC conforms to which screen etc? Not via RTCP like TIP = does.

I just want to point out that signalling this with a single m=3D line= in
SDP is impossible. As the general media type is part of the m=3D line one can't have both RTP payload types of both audio and video type in the same m=3D line.

When it comes to RTP RFC 3550 discusses this type of multiplexing and
has the following to say on the issue (from section 5.2 of RFC 3550):

=A0 For efficient protocol processing, the number of multiplexing points =A0 should be minimized, as described in the integrated layer processing =A0 design principle [10]. =A0In RTP, multiplexing is provided by the
=A0 destination transport address (network address and port number) which<= br> =A0 is different for each RTP session. =A0For example, in a teleconference=
=A0 composed of audio and video media encoded separately, each medium
=A0 SHOULD be carried in a separate RTP session with its own destination =A0 transport address.

=A0 Separate audio and video streams SHOULD NOT be carried in a single
=A0 RTP session and demultiplexed based on the payload type or SSRC
=A0 fields. =A0Interleaving packets with different RTP media types but
=A0 using the same SSRC would introduce several problems:

=A0 1. If, say, two audio streams shared the same RTP session and the
=A0 =A0 =A0same SSRC value, and one were to change encodings and thus acqu= ire
=A0 =A0 =A0a different RTP payload type, there would be no general way of<= br> =A0 =A0 =A0identifying which stream had changed encodings.

=A0 2. An SSRC is defined to identify a single timing and sequence number<= br> =A0 =A0 =A0space. =A0Interleaving multiple payload types would require
=A0 =A0 =A0different timing spaces if the media clock rates differ and wou= ld
=A0 =A0 =A0require different sequence number spaces to tell which payload<= br> =A0 =A0 =A0type suffered packet loss.

=A0 3. The RTCP sender and receiver reports (see Section 6.4) can only
=A0 =A0 =A0describe one timing and sequence number space per SSRC and do n= ot
=A0 =A0 =A0carry a payload type field.

=A0 4. An RTP mixer would not be able to combine interleaved streams of =A0 =A0 =A0incompatible media into one stream.

=A0 5. Carrying multiple media in one RTP session precludes: the use of =A0 =A0 =A0different network paths or network resource allocations if
=A0 =A0 =A0appropriate; reception of a subset of the media if desired, for=
=A0 =A0 =A0example just audio if video would exceed the available bandwidt= h;
=A0 =A0 =A0and receiver implementations that use separate processes for th= e
=A0 =A0 =A0different media, whereas using separate RTP sessions permits =A0 =A0 =A0either single- or multiple-process implementations.

=A0 Using a different SSRC for each medium but sending them in the same =A0 RTP session would avoid the first three problems but not the last
=A0 two.

=A0 On the other hand, multiplexing multiple related sources of the same =A0 medium in one RTP session using different SSRC values is the norm for<= br> =A0 multicast sessions. =A0The problems listed above don't apply: an R= TP
=A0 mixer can combine multiple audio sources, for example, and the same =A0 treatment is applicable for all of them. =A0It may also be appropriate=
=A0 to multiplex streams of the same medium using different SSRC values =A0 in other scenarios where the last two problems do not apply.


As can be seen if one puts audio and video in the same RTP session but
with unique SSRCs for each stream one still do need to take care.

Issue 4, can be solved by explicit signalling, but makes the solution
more fragile in cases with dynamic memberships. If you don't have the inforamtion about the stream mixing decisions are more difficult.

Issue 5, I think becomes important as soon as we talk about a
heterogeneous set of session participants. A case that are part of the
charter to consider and solve.

In general I think this discussion should up level for a while. Lets
start discussing the general architecture and use cases and what
requirements that puts on the different nodes in the architecture. Then
we can return to this and see what requirements we have and how they
matches the capabilities of the protocols we intended to solve it with.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Phone =A0+46 10 7148287
F=E4r=F6gatan 6 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------

--0015175ce0ccd6629b049b389663-- From alex@vidyo.com Tue Feb 1 06:34:42 2011 Return-Path: X-Original-To: clue@core3.amsl.com Delivered-To: clue@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 261943A6D0E for ; Tue, 1 Feb 2011 06:34:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o4lUwEPrZ4kM for ; Tue, 1 Feb 2011 06:34:39 -0800 (PST) Received: from mx1.myoutlookonline.com (mx1.myoutlookonline.com [64.95.72.238]) by core3.amsl.com (Postfix) with ESMTP id 23C973A6CF3 for ; Tue, 1 Feb 2011 06:34:39 -0800 (PST) Received: from st021.mx1.myoutlookonline.com (localhost [127.0.0.1]) by mx1.myoutlookonline.com (Postfix) with ESMTP id BEF1255350C; Tue, 1 Feb 2011 09:37:55 -0500 (EST) X-Virus-Scanned: by SpamTitan at mail.lan Received: from mx1.myoutlookonline.com (unknown [10.110.2.1]) by mx1.myoutlookonline.com (Postfix) with ESMTP id E18EA5534FD; Tue, 1 Feb 2011 09:37:54 -0500 (EST) Received: from BH017.mail.lan ([10.110.21.117]) by mx1.myoutlookonline.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Feb 2011 09:37:29 -0500 Received: from HUB027.mail.lan ([10.110.17.27]) by BH017.mail.lan with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Feb 2011 09:37:28 -0500 Received: from BE235.mail.lan ([10.110.32.235]) by HUB027.mail.lan ([10.110.17.27]) with mapi; Tue, 1 Feb 2011 09:37:44 -0500 From: Alex Eleftheriadis To: Stephen Botzko Date: Tue, 1 Feb 2011 09:37:51 -0500 Thread-Topic: [clue] Multiple Streams - RTP muxing? Thread-Index: AcvCHZX8H4C+TKWlS8yng4JWCcWeHQ== Message-ID: <596CBB52-4F55-4B7F-8099-D8070C34A6F0@vidyo.com> References: <9EEB6465-626A-43B9-A653-A9B67FC01E80@magorcorp.com> <4D46ADFD.8010506@ericsson.com> <4D4801B6.7020905@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_596CBB524F554B7F8099D8070C34A6F0vidyocom_" MIME-Version: 1.0 X-OriginalArrivalTime: 01 Feb 2011 14:37:28.0169 (UTC) FILETIME=[8CC40D90:01CBC21D] Cc: CLUE Subject: Re: [clue] Multiple Streams - RTP muxing? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 14:34:42 -0000 --_000_596CBB524F554B7F8099D8070C34A6F0vidyocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Feb 1, 2011, at 3:34 PM, Stephen Botzko wrote: >>> As the general media type is part of the m=3D line one can't have both RTP payload types of both audio and video type in the same m=3D line. >>>There might be some confusion here, I didn't hear anyone propose multipl= exing both audio and video in the same session. I believe the multiplex id= ea is to have two sessions, one for audio and one for video. This is what = existing video systems that employ multiplexing do. Yes, I don't think anyone intentionally suggested that the two (audio and v= ideo) are muxed. >>> In general I think this discussion should up level for a while. >>> Probably a good idea. This will come back, there are a lot of folks who bu= ild telepresence systems who favor SSRC multiplexing. Certainly (and this goes beyond pure telepresence). We will need some addit= ional signaling tools. Check out also draft-lennox-mmusic-sdp-source-select= ion-02, if you haven't already. For future discussion. Incidentally, since the iPad was mentioned, you can see a demonstration of = iPad running RTP (de)muxing of 3 H.264 streams in http://bit.ly/fMTP6j (pos= ted in August 2010). This is not a "demo"; this is our regular SDK running.= The complexity argument is really moot, in view of all the other things th= at happen in a server or endpoint. --Alex Stephen Botzko On Tue, Feb 1, 2011 at 7:51 AM, Magnus Westerlund > wrote: aravind sethuraman skrev 2011-01-31 20:03: > Hi all, > if we chose a single RTP session for ALL video and AUDIO, how will we > signal which SSRC conforms to which screen etc? Not via RTCP like TIP doe= s. I just want to point out that signalling this with a single m=3D line in SDP is impossible. As the general media type is part of the m=3D line one can't have both RTP payload types of both audio and video type in the same m=3D line. When it comes to RTP RFC 3550 discusses this type of multiplexing and has the following to say on the issue (from section 5.2 of RFC 3550): For efficient protocol processing, the number of multiplexing points should be minimized, as described in the integrated layer processing design principle [10]. In RTP, multiplexing is provided by the destination transport address (network address and port number) which is different for each RTP session. For example, in a teleconference composed of audio and video media encoded separately, each medium SHOULD be carried in a separate RTP session with its own destination transport address. Separate audio and video streams SHOULD NOT be carried in a single RTP session and demultiplexed based on the payload type or SSRC fields. Interleaving packets with different RTP media types but using the same SSRC would introduce several problems: 1. If, say, two audio streams shared the same RTP session and the same SSRC value, and one were to change encodings and thus acquire a different RTP payload type, there would be no general way of identifying which stream had changed encodings. 2. An SSRC is defined to identify a single timing and sequence number space. Interleaving multiple payload types would require different timing spaces if the media clock rates differ and would require different sequence number spaces to tell which payload type suffered packet loss. 3. The RTCP sender and receiver reports (see Section 6.4) can only describe one timing and sequence number space per SSRC and do not carry a payload type field. 4. An RTP mixer would not be able to combine interleaved streams of incompatible media into one stream. 5. Carrying multiple media in one RTP session precludes: the use of different network paths or network resource allocations if appropriate; reception of a subset of the media if desired, for example just audio if video would exceed the available bandwidth; and receiver implementations that use separate processes for the different media, whereas using separate RTP sessions permits either single- or multiple-process implementations. Using a different SSRC for each medium but sending them in the same RTP session would avoid the first three problems but not the last two. On the other hand, multiplexing multiple related sources of the same medium in one RTP session using different SSRC values is the norm for multicast sessions. The problems listed above don't apply: an RTP mixer can combine multiple audio sources, for example, and the same treatment is applicable for all of them. It may also be appropriate to multiplex streams of the same medium using different SSRC values in other scenarios where the last two problems do not apply. As can be seen if one puts audio and video in the same RTP session but with unique SSRCs for each stream one still do need to take care. Issue 4, can be solved by explicit signalling, but makes the solution more fragile in cases with dynamic memberships. If you don't have the inforamtion about the stream mixing decisions are more difficult. Issue 5, I think becomes important as soon as we talk about a heterogeneous set of session participants. A case that are part of the charter to consider and solve. In general I think this discussion should up level for a while. Lets start discussing the general architecture and use cases and what requirements that puts on the different nodes in the architecture. Then we can return to this and see what requirements we have and how they matches the capabilities of the protocols we intended to solve it with. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 F=E4r=F6gatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue --_000_596CBB524F554B7F8099D8070C34A6F0vidyocom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
On Feb 1, 2011, = at 3:34 PM, Stephen Botzko wrote:

>>>
As the general media type is = part of the m=3D line one
can't have both RTP payload types of both audio and video type in the
same m=3D line.
>>>There might be some confusion here, I didn't= hear anyone propose multiplexing both audio and video in the same session.=   I believe the multiplex idea is to have two sessions, one for audio = and one for video.  This is what existing video systems that employ mu= ltiplexing do.

Yes, I don't think anyone in= tentionally suggested that the two (audio and video) are muxed. 
=


>>>
In general I think this discussion should up level for = a while.
>>>
Probably a good idea.  This will come back= , there are a lot of folks who build telepresence systems who favor SSRC mu= ltiplexing.


Certainly (and this goes beyond pure t= elepresence). We will need some additional signaling tools. Check out = also draft-lennox-mmusic-sdp-source-selection-02, if you haven't alrea= dy. For future discussion.

Incidentally,= since the iPad was mentioned, you can see a demonstration of iPad running = RTP (de)muxing of 3 H.264 streams in = http://bit.ly/fMTP6j (posted in August 2010). This is not a "demo"; thi= s is our regular SDK running. The complexity argument is really moot, = in view of all the other things that happen in a server or endpoint. <= /div>

--Alex

Stephen Botzko

On Tue, Feb= 1, 2011 at 7:51 AM, Magnus Westerlund <magnus.westerlund@ericsson.com><= /span> wrote:
aravind sethurama= n skrev 2011-01-31 20:03:
> Hi all,
> if we chose a single RTP session for ALL video and AUDIO, how will we<= br> > signal which SSRC conforms to which screen etc? Not via RTCP like TIP = does.

I just want to point out that signalling this with a single m=3D line= in
SDP is impossible. As the general media type is part of the m=3D line one can't have both RTP payload types of both audio and video type in the
same m=3D line.

When it comes to RTP RFC 3550 discusses this type of multiplexing and
has the following to say on the issue (from section 5.2 of RFC 3550):

  For efficient protocol processing, the number of multiplexing point= s
  should be minimized, as described in the integrated layer processin= g
  design principle [10].  In RTP, multiplexing is provided by th= e
  destination transport address (network address and port number) whi= ch
  is different for each RTP session.  For example, in a teleconf= erence
  composed of audio and video media encoded separately, each medium   SHOULD be carried in a separate RTP session with its own destinatio= n
  transport address.

  Separate audio and video streams SHOULD NOT be carried in a single<= br>   RTP session and demultiplexed based on the payload type or SSRC
  fields.  Interleaving packets with different RTP media types b= ut
  using the same SSRC would introduce several problems:

  1. If, say, two audio streams shared the same RTP session and the      same SSRC value, and one were to change encodings and = thus acquire
     a different RTP payload type, there would be no genera= l way of
     identifying which stream had changed encodings.

  2. An SSRC is defined to identify a single timing and sequence numb= er
     space.  Interleaving multiple payload types would= require
     different timing spaces if the media clock rates diffe= r and would
     require different sequence number spaces to tell which= payload
     type suffered packet loss.

  3. The RTCP sender and receiver reports (see Section 6.4) can only<= br>      describe one timing and sequence number space per SSRC= and do not
     carry a payload type field.

  4. An RTP mixer would not be able to combine interleaved streams of=
     incompatible media into one stream.

  5. Carrying multiple media in one RTP session precludes: the use of=
     different network paths or network resource allocation= s if
     appropriate; reception of a subset of the media if des= ired, for
     example just audio if video would exceed the available= bandwidth;
     and receiver implementations that use separate process= es for the
     different media, whereas using separate RTP sessions p= ermits
     either single- or multiple-process implementations.
  Using a different SSRC for each medium but sending them in the same=
  RTP session would avoid the first three problems but not the last   two.

  On the other hand, multiplexing multiple related sources of the sam= e
  medium in one RTP session using different SSRC values is the norm f= or
  multicast sessions.  The problems listed above don't apply: an= RTP
  mixer can combine multiple audio sources, for example, and the same=
  treatment is applicable for all of them.  It may also be appro= priate
  to multiplex streams of the same medium using different SSRC values=
  in other scenarios where the last two problems do not apply.


As can be seen if one puts audio and video in the same RTP session but
with unique SSRCs for each stream one still do need to take care.

Issue 4, can be solved by explicit signalling, but makes the solution
more fragile in cases with dynamic memberships. If you don't have the
inforamtion about the stream mixing decisions are more difficult.

Issue 5, I think becomes important as soon as we talk about a
heterogeneous set of session participants. A case that are part of the
charter to consider and solve.

In general I think this discussion should up level for a while. Lets
start discussing the general architecture and use cases and what
requirements that puts on the different nodes in the architecture. Then
we can return to this and see what requirements we have and how they
matches the capabilities of the protocols we intended to solve it with.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone =  +46 10 7148287
F=E4r=F6gatan 6                | Mo= bile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------

_______________________________________________
clue mailing list
clue@ietf.org
https://www.ietf.org/mai= lman/listinfo/clue

= --_000_596CBB524F554B7F8099D8070C34A6F0vidyocom_-- From john.elwell@siemens-enterprise.com Tue Feb 1 07:31:18 2011 Return-Path: X-Original-To: clue@core3.amsl.com Delivered-To: clue@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50A7C3A6C1A for ; Tue, 1 Feb 2011 07:31:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.536 X-Spam-Level: X-Spam-Status: No, score=-102.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IbUqhnoMnbI0 for ; Tue, 1 Feb 2011 07:31:17 -0800 (PST) Received: from ms01.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 94C763A6C11 for ; Tue, 1 Feb 2011 07:31:16 -0800 (PST) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms01.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-3230565; Tue, 1 Feb 2011 16:34:32 +0100 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id DB6671EB82AB; Tue, 1 Feb 2011 16:34:32 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Tue, 1 Feb 2011 16:34:32 +0100 From: "Elwell, John" To: Stephen Botzko Date: Tue, 1 Feb 2011 16:34:31 +0100 Thread-Topic: [clue] Multiple Streams - RTP muxing? Thread-Index: AcvCBvSL85v4YfMKQO6PF2iru3GLmgAHS+3Q Message-ID: References: <9EEB6465-626A-43B9-A653-A9B67FC01E80@magorcorp.com> <4D46ADFD.8010506@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: CLUE Subject: Re: [clue] Multiple Streams - RTP muxing? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 15:31:18 -0000 =20 > -----Original Message----- > From: Stephen Botzko [mailto:stephen.botzko@gmail.com]=20 > Sent: 01 February 2011 11:56 > To: Elwell, John > Cc: Charles Eckel (eckelcu); Magnus Westerlund; CLUE > Subject: Re: [clue] Multiple Streams - RTP muxing? >=20 > The use cases and the problem statement drafts were not=20 > intended to be requirements documents. I agree that=20 > scalability needs to be discussed, and that use cases for=20 > large scale conferences are needed. [JRE] That's what I thought. So perhaps we do need to start assembling requ= irements, although I am not suggesting that should prevent us having these = discussions on solution. >=20 > Existing telepresence systems I am aware of receive/decode=20 > one video stream per display. =20 >=20 > However, it is quite practical to send one video stream per=20 > rendered image (instead of using video transcoding),=20 > especially if the sender either simulcasts multiple=20 > resolutions or uses a layered video codec like SVC. This can=20 > greatly increase the number of streams that are received at=20 > each endpoint, and also makes the received stream mix much=20 > more dynamic. One benefit is that transcoding/transrating=20 > 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) o= r at the SDP level. John >=20 > Both approaches were listed in the problem statement draft=20 > last year (in the multipoint section). Personally I favor a=20 > solution that accommodates both. >=20 > Stephen Botzko >=20 >=20 > On Tue, Feb 1, 2011 at 6:30 AM, Elwell, John=20 > wrote: >=20 >=20 > I really think we should have some sort of=20 > understanding on scalability requirements here. I don't think=20 > this is covered in either of the two drafts to date, but I=20 > may have missed it. > =09 > John > =09 >=20 > > -----Original Message----- > > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On > =09 > > Behalf Of Charles Eckel (eckelcu) > =09 > > 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: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] > > 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=20 > 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 > > 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=20 > transcoding, or a new > > > multiplexing mechanism? > > > > > > 2. One RTP session, with one SSRC per original=20 > video stream. > > > > > > So please be clear on what you are discussing and > > suggesting here. > > > > > > Cheers > > > > > > Magnus Westerlund > > > > > > > >=20 > ---------------------------------------------------------------------- > > > Multimedia Technologies, Ericsson Research EAB/TVM > > > > >=20 > ---------------------------------------------------------------------- > > > Ericsson AB | Phone +46 10 7148287 > > > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > > > SE-164 80 Stockholm, Sweden| mailto: > > magnus.westerlund@ericsson.com > > > > >=20 > ---------------------------------------------------------------------- > > > > > > _______________________________________________ > > > clue mailing list > > > clue@ietf.org > > > https://www.ietf.org/mailman/listinfo/clue > > > > > > > > > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue > >=20 >=20 >=20 > = From bruno.chatras@orange-ftgroup.com Tue Feb 1 09:21:38 2011 Return-Path: X-Original-To: clue@core3.amsl.com Delivered-To: clue@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F1613A6AE5 for ; Tue, 1 Feb 2011 09:21:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QQtj2GJh3iDI for ; Tue, 1 Feb 2011 09:21:28 -0800 (PST) Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by core3.amsl.com (Postfix) with ESMTP id AD3683A6DF4 for ; Tue, 1 Feb 2011 09:21:27 -0800 (PST) Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 8CBA5FC400B; Tue, 1 Feb 2011 18:24:48 +0100 (CET) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id CBB2DFC4020; Tue, 1 Feb 2011 18:24:46 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 1 Feb 2011 18:24:42 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBC234.E8E31F43" Date: Tue, 1 Feb 2011 18:22:41 +0100 Message-ID: <9ECCF01B52E7AB408A7EB8535264214102760898@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <596CBB52-4F55-4B7F-8099-D8070C34A6F0@vidyo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] Multiple Streams - RTP muxing? Thread-Index: AcvCHZX8H4C+TKWlS8yng4JWCcWeHQAFmbqA References: <9EEB6465-626A-43B9-A653-A9B67FC01E80@magorcorp.com><4D46ADFD.8010506@ericsson.com><4D4801B6.7020905@ericsson.com> <596CBB52-4F55-4B7F-8099-D8070C34A6F0@vidyo.com> From: To: , X-OriginalArrivalTime: 01 Feb 2011 17:24:42.0013 (UTC) FILETIME=[E96724D0:01CBC234] Cc: clue@ietf.org Subject: Re: [clue] Multiple Streams - RTP muxing? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 17:21:38 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBC234.E8E31F43 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable If we use a single RTP session for all video streams (or audio streams) = and stream-specific properties (e.g. stream position or image format) = have to be signaled, then I guess RFC5576 will come into play.... = Right? =20 /Bruno =20 =20 De : clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] De la part de = Alex Eleftheriadis Envoy=E9 : mardi 1 f=E9vrier 2011 15:38 =C0 : Stephen Botzko Cc : CLUE Objet : Re: [clue] Multiple Streams - RTP muxing? =20 On Feb 1, 2011, at 3:34 PM, Stephen Botzko wrote: >>> As the general media type is part of the m=3D line one can't have both RTP payload types of both audio and video type in the same m=3D line. >>>There might be some confusion here, I didn't hear anyone propose = multiplexing both audio and video in the same session. I believe the = multiplex idea is to have two sessions, one for audio and one for video. = This is what existing video systems that employ multiplexing do.=20 =20 Yes, I don't think anyone intentionally suggested that the two (audio = and video) are muxed.=20 =20 =09 >>> In general I think this discussion should up level for a while. >>> Probably a good idea. This will come back, there are a lot of folks = who build telepresence systems who favor SSRC multiplexing.=20 =20 Certainly (and this goes beyond pure telepresence). We will need some = additional signaling tools. Check out also = draft-lennox-mmusic-sdp-source-selection-02, if you haven't already. For = future discussion. =20 Incidentally, since the iPad was mentioned, you can see a demonstration = of iPad running RTP (de)muxing of 3 H.264 streams in = http://bit.ly/fMTP6j (posted in August 2010). This is not a "demo"; this = is our regular SDK running. The complexity argument is really moot, in = view of all the other things that happen in a server or endpoint.=20 =20 --Alex Stephen Botzko On Tue, Feb 1, 2011 at 7:51 AM, Magnus Westerlund = wrote: aravind sethuraman skrev 2011-01-31 20:03: > Hi all, > if we chose a single RTP session for ALL video and AUDIO, how will we > signal which SSRC conforms to which screen etc? Not via RTCP like TIP = does. I just want to point out that signalling this with a single m=3D line in SDP is impossible. As the general media type is part of the m=3D line = one can't have both RTP payload types of both audio and video type in the same m=3D line. When it comes to RTP RFC 3550 discusses this type of multiplexing and has the following to say on the issue (from section 5.2 of RFC 3550): For efficient protocol processing, the number of multiplexing points should be minimized, as described in the integrated layer processing design principle [10]. In RTP, multiplexing is provided by the destination transport address (network address and port number) which is different for each RTP session. For example, in a teleconference composed of audio and video media encoded separately, each medium SHOULD be carried in a separate RTP session with its own destination transport address. Separate audio and video streams SHOULD NOT be carried in a single RTP session and demultiplexed based on the payload type or SSRC fields. Interleaving packets with different RTP media types but using the same SSRC would introduce several problems: 1. If, say, two audio streams shared the same RTP session and the same SSRC value, and one were to change encodings and thus acquire a different RTP payload type, there would be no general way of identifying which stream had changed encodings. 2. An SSRC is defined to identify a single timing and sequence number space. Interleaving multiple payload types would require different timing spaces if the media clock rates differ and would require different sequence number spaces to tell which payload type suffered packet loss. 3. The RTCP sender and receiver reports (see Section 6.4) can only describe one timing and sequence number space per SSRC and do not carry a payload type field. 4. An RTP mixer would not be able to combine interleaved streams of incompatible media into one stream. 5. Carrying multiple media in one RTP session precludes: the use of different network paths or network resource allocations if appropriate; reception of a subset of the media if desired, for example just audio if video would exceed the available bandwidth; and receiver implementations that use separate processes for the different media, whereas using separate RTP sessions permits either single- or multiple-process implementations. Using a different SSRC for each medium but sending them in the same RTP session would avoid the first three problems but not the last two. On the other hand, multiplexing multiple related sources of the same medium in one RTP session using different SSRC values is the norm for multicast sessions. The problems listed above don't apply: an RTP mixer can combine multiple audio sources, for example, and the same treatment is applicable for all of them. It may also be appropriate to multiplex streams of the same medium using different SSRC values in other scenarios where the last two problems do not apply. As can be seen if one puts audio and video in the same RTP session but with unique SSRCs for each stream one still do need to take care. Issue 4, can be solved by explicit signalling, but makes the solution more fragile in cases with dynamic memberships. If you don't have the inforamtion about the stream mixing decisions are more difficult. Issue 5, I think becomes important as soon as we talk about a heterogeneous set of session participants. A case that are part of the charter to consider and solve. In general I think this discussion should up level for a while. Lets start discussing the general architecture and use cases and what requirements that puts on the different nodes in the architecture. Then we can return to this and see what requirements we have and how they matches the capabilities of the protocols we intended to solve it with. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 F=E4r=F6gatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue =20 ------_=_NextPart_001_01CBC234.E8E31F43 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

If we use a single RTP session for all video streams (or = audio streams) and stream-specific properties (e.g. stream position or image = format) have to be signaled, then I guess RFC5576 will come into play…. = =A0Right?

 

/Bruno

 

 

De : clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] De la part = de Alex Eleftheriadis
Envoy=E9 : mardi 1 f=E9vrier 2011 15:38
=C0 : Stephen Botzko
Cc : CLUE
Objet : Re: [clue] Multiple Streams - RTP = muxing?

 

On Feb 1, 2011, at 3:34 PM, Stephen Botzko = wrote:



>>>
As the general media type is part of the m=3D line one
can't have both RTP payload types of both audio and video type in = the
same m=3D line.
>>>There might be some confusion here, I didn't hear anyone = propose multiplexing both audio and video in the same session.  I believe = the multiplex idea is to have two sessions, one for audio and one for = video.  This is what existing video systems that employ multiplexing do. =

 

Yes, I don't think anyone intentionally suggested = that the two (audio and video) are muxed. 

 


>>>
In general I think this discussion should up level for a while.
>>>
Probably a good idea.  This will come back, there are a lot of = folks who build telepresence systems who favor SSRC multiplexing.

 

Certainly (and this goes beyond pure = telepresence). We will need some additional signaling tools. Check out also draft-lennox-mmusic-sdp-source-selection-02, if you haven't = already. For future discussion.

 

Incidentally, since the iPad was mentioned, you can = see a demonstration of iPad running RTP (de)muxing of 3 H.264 streams = in http://bit.ly/fMTP6j (posted in August = 2010). This is not a "demo"; this is our regular SDK = running. The complexity argument is really moot, in view of all the other things that = happen in a server or endpoint. 

 

--Alex



Stephen = Botzko

On Tue, Feb 1, 2011 at 7:51 AM, Magnus Westerlund = <magnus.westerlund@ericsson= .com> wrote:

aravind sethuraman skrev 2011-01-31 = 20:03:

> Hi all,
> if we chose a single RTP session for ALL video and AUDIO, how will = we
> signal which SSRC conforms to which screen etc? Not via RTCP like = TIP does.

I just want to point out that signalling this with = a single m=3D line in
SDP is impossible. As the general media type is part of the m=3D line = one
can't have both RTP payload types of both audio and video type in = the
same m=3D line.

When it comes to RTP RFC 3550 discusses this type of multiplexing = and
has the following to say on the issue (from section 5.2 of RFC = 3550):

  For efficient protocol processing, the number of multiplexing = points
  should be minimized, as described in the integrated layer = processing
  design principle [10].  In RTP, multiplexing is provided by = the
  destination transport address (network address and port number) = which
  is different for each RTP session.  For example, in a = teleconference
  composed of audio and video media encoded separately, each = medium
  SHOULD be carried in a separate RTP session with its own = destination
  transport address.

  Separate audio and video streams SHOULD NOT be carried in a = single
  RTP session and demultiplexed based on the payload type or = SSRC
  fields.  Interleaving packets with different RTP media types = but
  using the same SSRC would introduce several problems:

  1. If, say, two audio streams shared the same RTP session and = the
     same SSRC value, and one were to change encodings = and thus acquire
     a different RTP payload type, there would be no = general way of
     identifying which stream had changed encodings.

  2. An SSRC is defined to identify a single timing and sequence = number
     space.  Interleaving multiple payload types = would require
     different timing spaces if the media clock rates = differ and would
     require different sequence number spaces to tell = which payload
     type suffered packet loss.

  3. The RTCP sender and receiver reports (see Section 6.4) can = only
     describe one timing and sequence number space per = SSRC and do not
     carry a payload type field.

  4. An RTP mixer would not be able to combine interleaved streams = of
     incompatible media into one stream.

  5. Carrying multiple media in one RTP session precludes: the use = of
     different network paths or network resource = allocations if
     appropriate; reception of a subset of the media if = desired, for
     example just audio if video would exceed the = available bandwidth;
     and receiver implementations that use separate = processes for the
     different media, whereas using separate RTP sessions permits
     either single- or multiple-process = implementations.

  Using a different SSRC for each medium but sending them in the = same
  RTP session would avoid the first three problems but not the = last
  two.

  On the other hand, multiplexing multiple related sources of the = same
  medium in one RTP session using different SSRC values is the norm = for
  multicast sessions.  The problems listed above don't apply: = an RTP
  mixer can combine multiple audio sources, for example, and the = same
  treatment is applicable for all of them.  It may also be appropriate
  to multiplex streams of the same medium using different SSRC = values
  in other scenarios where the last two problems do not apply.


As can be seen if one puts audio and video in the same RTP session = but
with unique SSRCs for each stream one still do need to take care.

Issue 4, can be solved by explicit signalling, but makes the = solution
more fragile in cases with dynamic memberships. If you don't have = the
inforamtion about the stream mixing decisions are more difficult.

Issue 5, I think becomes important as soon as we talk about a
heterogeneous set of session participants. A case that are part of = the
charter to consider and solve.

In general I think this discussion should up level for a while. Lets
start discussing the general architecture and use cases and what
requirements that puts on the different nodes in the architecture. = Then
we can return to this and see what requirements we have and how they
matches the capabilities of the protocols we intended to solve it = with.


Cheers

Magnus Westerlund

---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM
---------------------------------------------------------------------- Ericsson AB                | = Phone  +46 10 7148287
F=E4r=F6gatan 6                | = Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson= .com
----------------------------------------------------------------------


_______________________________________________
clue mailing list
clue@ietf.org
https://www.ietf.org/mailman/listinfo/clue

 

------_=_NextPart_001_01CBC234.E8E31F43-- From Henry.Lum@alcatel-lucent.com Tue Feb 1 09:39:58 2011 Return-Path: X-Original-To: clue@core3.amsl.com Delivered-To: clue@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EB3A3A6D4A for ; Tue, 1 Feb 2011 09:39:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.201 X-Spam-Level: X-Spam-Status: No, score=-6.201 tagged_above=-999 required=5 tests=[AWL=0.398, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2gRD4z0FVFPU for ; Tue, 1 Feb 2011 09:39:57 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id 486593A6C56 for ; Tue, 1 Feb 2011 09:39:57 -0800 (PST) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id p11HhCna022032 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 1 Feb 2011 11:43:12 -0600 (CST) Received: from relay-out2.dc (relay-out2.dc.genesyslab.com [172.22.68.188]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p11HhAPh012356 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 1 Feb 2011 11:43:12 -0600 Received: from g2.genesyslab.com (g2.genesyslab.com [192.168.20.138]) by relay-out2.dc (8.13.8+Sun/8.13.8) with ESMTP id p11Hh9Ef019643; Tue, 1 Feb 2011 09:43:09 -0800 (PST) Received: from NAHALD.us.int.genesyslab.com ([192.168.20.92]) by g2.genesyslab.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 1 Feb 2011 09:43:09 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 1 Feb 2011 09:43:08 -0800 Message-ID: <059AF07365DC474393A19A3AF187DF7406A1EFA3@NAHALD.us.int.genesyslab.com> In-Reply-To: <7A6BA6C5-F192-43CB-82F1-10DEB1CC7C3E@vidyo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] Multiple Streams - RTP muxing? Thread-Index: AcvBi+xcjJaQia7OQ5eyD6mN8TV2cgAqp9lQ References: <9EEB6465-626A-43B9-A653-A9B67FC01E80@magorcorp.com><4D46ADFD.8010506@ericsson.com> <7A6BA6C5-F192-43CB-82F1-10DEB1CC7C3E@vidyo.com> From: "Henry Lum" To: "Jonathan Lennox" , "Charles Eckel (eckelcu)" X-OriginalArrivalTime: 01 Feb 2011 17:43:09.0370 (UTC) FILETIME=[7D7069A0:01CBC237] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 X-Mailman-Approved-At: Tue, 01 Feb 2011 10:00:53 -0800 Cc: CLUE Subject: Re: [clue] Multiple Streams - RTP muxing? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 17:39:58 -0000 I agree that SSRC multiplexing makes a lot of sense for this use case. Trying to match m=3D lines even with the same number of cameras on both endpoints can be ambiguous; how do you know which cameras to pair up?=20 Henry > As mentioned previously, this simplifies NAT/firewall traversal > substantially. It also makes asymmetric cases clearer -- if I have > three cameras and you have two, it's very unclear to me how my m=3D lines > should map to your m=3D lines if we wanted to use the single-source-per= - > session model, whereas for SSRC multiplexing it's straightforward. =09 -------------------------------------------------------------------------= ------------------------------------------ CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain co= nfidential and proprietary information of Alcatel-Lucent and/or its affil= iated entities. Access by the intended recipient only is authorized. Any = liability arising from any party acting, or refraining from acting, on an= y information contained in this e-mail is hereby excluded. If you are not= the intended recipient, please notify the sender immediately, destroy th= e original transmission and its attachments and do not disclose the conte= nts to any other person, use it for any purpose, or store or copy the inf= ormation in any medium. Copyright in this e-mail and any attachments belo= ngs to Alcatel-Lucent and/or its affiliated entities. =09 From mary.ietf.barnes@gmail.com Tue Feb 1 14:59:18 2011 Return-Path: X-Original-To: clue@core3.amsl.com Delivered-To: clue@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2092A3A6D7D for ; Tue, 1 Feb 2011 14:59:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.346 X-Spam-Level: X-Spam-Status: No, score=-103.346 tagged_above=-999 required=5 tests=[AWL=0.252, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sFLssrhvFhE6 for ; Tue, 1 Feb 2011 14:59:14 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id EA84B3A6D23 for ; Tue, 1 Feb 2011 14:59:13 -0800 (PST) Received: by gyd12 with SMTP id 12so3108544gyd.31 for ; Tue, 01 Feb 2011 15:02:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to:cc :content-type; bh=JLscbrOOrn3vEI3AAir9qIHzSc4kJ4zgGrqwWh5TnaI=; b=F16t0JQiSUaqeR74j/1QEheVGpKIbR+wCH6Ma0THUAgEDWplVH4J4/s0gP9P+R2YBB +ziBuB4hV0qS8xU7LpjNhTYbSQOca7Je8mXa+Fa6ko2PQ6N91yIQyhw7cxfwctt1gMnR HhV9RXxCGdlZ8esAM9tQWP7KWL1POcZ/xdqFM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=cFm3W5VzEGTWMKZ1TE5dtqGnkAcMLreG6kgZ5bneUOWCVm/tm6S1zJfleu5mPLnq8j 2cP62fqDnUDX/IPxsVKdCa6b/xnGf8vma0ZTA+5lcLduF2ra6MAkH/nzmqEFBDLs7UK4 ZnLbc07vv4kd5ZJBjT71d1CeHkqt2EXICeolA= MIME-Version: 1.0 Received: by 10.236.95.143 with SMTP id p15mr17175428yhf.9.1296601351584; Tue, 01 Feb 2011 15:02:31 -0800 (PST) Received: by 10.236.95.35 with HTTP; Tue, 1 Feb 2011 15:02:31 -0800 (PST) Date: Tue, 1 Feb 2011 17:02:31 -0600 Message-ID: From: Mary Barnes To: "Elwell, John" Content-Type: multipart/alternative; boundary=0023547c895bf9fc94049b4086f9 Cc: CLUE Subject: [clue] Requirements & use cases ( was Re: Multiple Streams - RTP muxing? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 22:59:18 -0000 --0023547c895bf9fc94049b4086f9 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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 pe= r 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 < john.elwell@siemens-enterprise.com> wrote: > > > > -----Original Message----- > > From: Stephen Botzko [mailto:stephen.botzko@gmail.com] > > 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 fo= r > multiplexing at the transport level, presumably there is then the questio= n > 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 > > 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: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] 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: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] > > > 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 > > > 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=E4r=F6gatan 6 | Mobile +46 73 0949079 > > > > SE-164 80 Stockholm, Sweden| mailto: > > > magnus.westerlund@ericsson.com > > > > > > > > > ---------------------------------------------------------------------- > > > > > > > > _______________________________________________ > > > > clue mailing list > > > > clue@ietf.org > > > > https://www.ietf.org/mailman/listinfo/clue > > > > > > > > > > > > > > _______________________________________________ > > > clue mailing list > > > clue@ietf.org > > > https://www.ietf.org/mailman/listinfo/clue > > > > > > > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > --0023547c895bf9fc94049b4086f9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Folks,
=A0
John has an excellent point wrt requirements. It will be extremely hel= pful to start defining the requirements which are a WG deliverable.=A0 Ally= n 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 mi= nd, please send text directly to Allyn=A0or post on the mailing list. Note,= that I changed the title of this thread in case folks reply directly.
=A0
In addition, it would be really good to get WG feedback on the use cas= es per Allyn's recent email:
http://www.ietf.org/mail-archive/web/clue/current/msg00074.html
Please reply separately to that thread.
=A0
As John notes, this isn't to say folks shouldn't be considerin= g solutions, it's just that we also need to make sure that there is suf= ficient focus and effort into the first two WG deliverables.=A0 If we don&#= 39;t get those completed in a timely manner, we won't get to defining t= he solution.
=A0
Thanks,
Mary.
CLUE WG co-chair
=A0
=A0
On Tue, Feb 1, 2011 at 9:34 AM, Elwell, John <john.elwell@siemens-ente= rprise.com> wrote:


> -----Original Message-----
> From: Ste= phen Botzko [mailto:stephen.bot= zko@gmail.com]
> Sent: 01 February 2011 11:56
> To: Elwell, Joh= n
> Cc: Charles Eckel (eckelcu); Magnus Westerlund; CLUE
> Subj= ect: Re: [clue] Multiple Streams - RTP muxing?
>
> The use cases and the problem statement drafts were = not
> intended to be requirements documents. =A0I agree that
> = scalability needs to be discussed, and that use cases for
> large sca= le conferences are needed.
[JRE] That's what I thought. So perhaps we do need to start assem= bling requirements, although I am not suggesting that should prevent us hav= ing these discussions on solution.

>
> Existing telepresence systems I am aware= of receive/decode
> one video stream per display.
>
> Ho= wever, it is quite practical to send one video stream per
> rendered = image (instead of using video transcoding),
> especially if the sender either simulcasts multiple
> resolution= s or uses a layered video codec like SVC. =A0This can
> greatly incre= ase the number of streams that are received at
> each endpoint, and a= lso makes the received stream mix much
> more dynamic. One benefit is that transcoding/transrating
> dela= y is at least reduced and in many cases eliminated.
[JRE] You ment= ion the mix being much more dynamic. So if we were to go for multiplexing a= t the transport level, presumably there is then the question of whether cha= nges are negotiated at the RTP level (likely to be quicker) or at the SDP l= evel.

John


>
> Both approaches were listed in the p= roblem statement draft
> last year (in the multipoint section). =A0Pe= rsonally I favor a
> solution that accommodates both.
>
>= Stephen Botzko
>
>
> On Tue, Feb 1, 2011 at 6:30 AM, Elwell, John
> &= lt;john.elwell@siemen= s-enterprise.com> wrote:
>
>
> =A0 =A0 =A0 I reall= y think we should have some sort of
> understanding on scalability requirements here. I don't think
&= gt; this is covered in either of the two drafts to date, but I
> may = have missed it.
>
> =A0 =A0 =A0 John
>
>
> = =A0 =A0 =A0 > -----Original Message-----
> =A0 =A0 =A0 > From: clue-b= ounces@ietf.org [mailto:clue-b= ounces@ietf.org] On
>
> =A0 =A0 =A0 > Behalf Of Charles = Eckel (eckelcu)
>
> =A0 =A0 =A0 > Sent: 31 January 2011 15:50
> =A0 =A0 = =A0 > To: Stephen Botzko; Magnus Westerlund
> =A0 =A0 =A0 > Cc:= CLUE
> =A0 =A0 =A0 > Subject: Re: [clue] Multiple Streams - RTP m= uxing?
> =A0 =A0 =A0 >
> =A0 =A0 =A0 > I was thinking (2) as well; however, one concern I ha= ve is
> =A0 =A0 =A0 > scalability. As the number of screens increa= ses from 3 or so
> =A0 =A0 =A0 > to say 10 or 100, does the set of= pros and cons change. I
> =A0 =A0 =A0 > would hate to have 100 m-lines, but 100 streams each = with its
> =A0 =A0 =A0 > own SSRC multiplexed in a single RTP sess= ion may be
> =A0 =A0 =A0 > programmatic as well.
> =A0 =A0 = =A0 > I am hoping those more familiar with the complexities and
> =A0 =A0 =A0 > limitations of RTP stream processing can chime in. Wi= ll we
> =A0 =A0 =A0 > have no choice but to break it into multiple= RTP sessions?
> =A0 =A0 =A0 >
> =A0 =A0 =A0 > Thanks,> =A0 =A0 =A0 > Charles
> =A0 =A0 =A0 >
> =A0 =A0 =A0 > > -----Original Message--= ---
> =A0 =A0 =A0 > > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org]
> =A0 =A0 =A0 > On Behalf Of Stephen Botzko
> =A0 =A0 =A0 > = > Sent: Monday, January 31, 2011 4:52 AM
> =A0 =A0 =A0 > > T= o: Magnus Westerlund
> =A0 =A0 =A0 > > Cc: CLUE
> =A0 =A0= =A0 > > Subject: Re: [clue] Multiple Streams - RTP muxing?
> =A0 =A0 =A0 > >
> =A0 =A0 =A0 > > Hi
> =A0 =A0= =A0 > > >>>
> =A0 =A0 =A0 > > 1. One RTP sessio= n, with one SSRC that contains the
> =A0 =A0 =A0 > encoding of mul= tiple
> =A0 =A0 =A0 > > different original flows through either=
> transcoding, or a new
> =A0 =A0 =A0 > > multiplexing mecha= nism?
> =A0 =A0 =A0 > >
> =A0 =A0 =A0 > > 2. One RT= P session, with one SSRC per original video stream.
> =A0 =A0 =A0 >= ; > >>>
> =A0 =A0 =A0 > >
> =A0 =A0 =A0 > > I was thinking (2)= . =A0(one session for audio and one for
> =A0 =A0 =A0 > video). = =A0I'd be open to (1) if it did not
> =A0 =A0 =A0 > > requi= re transcoding. =A0However, I am not convinced a totally
> =A0 =A0 =A0 > new mechanism is needed.
> =A0 =A0 =A0 > >= ;
> =A0 =A0 =A0 > > Though it hasn't come up yet, I was als= o wondering about
> =A0 =A0 =A0 > having all video and audio strea= ms from the
> =A0 =A0 =A0 > > same CLUE endpoint use the same c= lock offset, in order to
> =A0 =A0 =A0 > simplify lip-sync management with multiple
> = =A0 =A0 =A0 > > audio and multiple video streams. =A0Not sure about t= hat, but
> =A0 =A0 =A0 > I do see a lot of complexity in
> = =A0 =A0 =A0 > > determining the proper delays.
> =A0 =A0 =A0 > >
> =A0 =A0 =A0 > > Stephen Botzko
= > =A0 =A0 =A0 > >
> =A0 =A0 =A0 > >
> =A0 =A0 = =A0 > >
> =A0 =A0 =A0 > > On Mon, Jan 31, 2011 at 7:41 AM= , Magnus Westerlund
> =A0 =A0 =A0 > <magnus.westerlund@ericsson.com> wrote:
> =A0 =A0 =A0 > >
> =A0 =A0 =A0 > >
> =A0 =A0 = =A0 > > =A0 =A0 Hi,
> =A0 =A0 =A0 > >
> =A0 =A0 =A0= > > =A0 =A0 (AS AVTCore Chair)
> =A0 =A0 =A0 > >
>= =A0 =A0 =A0 > > =A0 =A0 I want to inject into this discussion a requ= est to be a
> =A0 =A0 =A0 > bit more clear
> =A0 =A0 =A0 > > =A0 =A0 = on what people are considering. Because RTP has several
> =A0 =A0 =A0= > multiplexing
> =A0 =A0 =A0 > > =A0 =A0 points and some ma= y even want to go furhter than the
> =A0 =A0 =A0 > existing ones. So
> =A0 =A0 =A0 > > =A0 = =A0 can everyone please clarify what they are talking about.
> =A0 = =A0 =A0 > >
> =A0 =A0 =A0 > > =A0 =A0 Please keep in mind= that RTP has certain point of where
> =A0 =A0 =A0 > things are
> =A0 =A0 =A0 > > =A0 =A0 inte= nded to separated. This also affects the
> =A0 =A0 =A0 > possibili= ty to use existing
> =A0 =A0 =A0 > > =A0 =A0 RTP tools.
>= =A0 =A0 =A0 > >
> =A0 =A0 =A0 > > =A0 =A0 So a primer in= RTP terminology:
> =A0 =A0 =A0 > >
> =A0 =A0 =A0 > > =A0 =A0 RTP Sessio= n: One SSRC space, normally determined based
> =A0 =A0 =A0 > on tr= ansport
> =A0 =A0 =A0 > > =A0 =A0 level ports. Each RTP session= normally servers one
> =A0 =A0 =A0 > media type and one
> =A0 =A0 =A0 > > =A0 =A0 purpose. Using different media types (au= dio and video)
> =A0 =A0 =A0 > will creates
> =A0 =A0 =A0 &g= t; > =A0 =A0 issues for some tools and SDP based signalling.
> =A0= =A0 =A0 > >
> =A0 =A0 =A0 > > =A0 =A0 SSRC, a single med= ia stream source. Multiple SSRC can
> =A0 =A0 =A0 > be used in the
> =A0 =A0 =A0 > > =A0 =A0 = same RTP session.
> =A0 =A0 =A0 > >
> =A0 =A0 =A0 > &g= t; =A0 =A0 RTP payload type, identifies the encoding of the RTP
> =A0= =A0 =A0 > payload. Thus
> =A0 =A0 =A0 > > =A0 =A0 possibly = identifying video screen sizes etc.
> =A0 =A0 =A0 > >
> =A0 =A0 =A0 > > =A0 =A0 So I will = start with asking Peter to clarify the below
> =A0 =A0 =A0 > state= ment:
> =A0 =A0 =A0 > >
> =A0 =A0 =A0 > > =A0 =A0 P= eter Musgrave skrev 2011-01-29 08:51:
> =A0 =A0 =A0 > >
> =A0 =A0 =A0 > > =A0 =A0 >
&g= t; =A0 =A0 =A0 > > =A0 =A0 > I think the notion of a single, multi= plexed video
> =A0 =A0 =A0 > stream for a TP endpoint makes a lot = of
> =A0 =A0 =A0 > > sense in the context of CLUE.
> =A0 =A0 =A0 > >
> =A0 =A0 =A0 > >
> =A0 =A0 = =A0 > > =A0 =A0 I can interpret this as meaning either of:
> = =A0 =A0 =A0 > >
> =A0 =A0 =A0 > > =A0 =A0 1. One RTP sess= ion, with one SSRC that contains the
> =A0 =A0 =A0 > encoding of multiple
> =A0 =A0 =A0 > > = =A0 =A0 different original flows through either
> transcoding, or a n= ew
> =A0 =A0 =A0 > > =A0 =A0 multiplexing mechanism?
> = =A0 =A0 =A0 > >
> =A0 =A0 =A0 > > =A0 =A0 2. One RTP sess= ion, with one SSRC per original
> video stream.
> =A0 =A0 =A0 > >
> =A0 =A0 =A0 > &= gt; =A0 =A0 So please be clear on what you are discussing and
> =A0 = =A0 =A0 > suggesting here.
> =A0 =A0 =A0 > >
> =A0 =A0= =A0 > > =A0 =A0 Cheers
> =A0 =A0 =A0 > >
> =A0 =A0 =A0 > > =A0 =A0 Magnus Westerlund
> =A0 =A0 =A0 &g= t; >
> =A0 =A0 =A0 > >
> =A0 =A0 =A0 >
> ----= ------------------------------------------------------------------
> = =A0 =A0 =A0 > > =A0 =A0 Multimedia Technologies, Ericsson Research EA= B/TVM
> =A0 =A0 =A0 > >
> =A0 =A0 =A0 >
> ---------------= -------------------------------------------------------
> =A0 =A0 =A0= > > =A0 =A0 Ericsson AB =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Phone =A0+4= 6 10 7148287
> =A0 =A0 =A0 > > =A0 =A0 F=E4r=F6gatan 6 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0| Mobile +46 73 0949079
> =A0 =A0 =A0 > > =A0 =A0 SE-164 80 Stockholm, Sweden| mailto:
= > =A0 =A0 =A0 > mag= nus.westerlund@ericsson.com
> =A0 =A0 =A0 > >
> =A0 = =A0 =A0 >
> ------------------------------------------------------= ----------------
> =A0 =A0 =A0 > >
> =A0 =A0 =A0 > > =A0 =A0 __________= _____________________________________
> =A0 =A0 =A0 > > =A0 =A0= clue mailing list
> =A0 =A0 =A0 > > =A0 =A0 clue@ietf.org
> =A0 =A0 =A0 > > =A0 =A0 https://www.ietf.org/mailman/listinfo/clue=
> =A0 =A0 =A0 > >
> =A0 =A0 =A0 > >
> = =A0 =A0 =A0 >
> =A0 =A0 =A0 > _________________________________= ______________
> =A0 =A0 =A0 > clue mailing list
> =A0 =A0 =A0 > clue@ietf.org
> =A0 =A0 =A0 > https://w= ww.ietf.org/mailman/listinfo/clue
> =A0 =A0 =A0 >
>
>
>
__________________________= _____________________
clue mailing list
clue@ietf.org
https://www.ietf.org/mailman/listinfo/clue

--0023547c895bf9fc94049b4086f9-- From peter.musgrave@magorcorp.com Tue Feb 1 21:54:22 2011 Return-Path: X-Original-To: clue@core3.amsl.com Delivered-To: clue@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 900BC3A702A for ; Tue, 1 Feb 2011 21:54:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2jzpfv4VyI5q for ; Tue, 1 Feb 2011 21:54:21 -0800 (PST) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by core3.amsl.com (Postfix) with ESMTP id 922EB3A6E88 for ; Tue, 1 Feb 2011 21:54:21 -0800 (PST) Received: by wwi17 with SMTP id 17so5640330wwi.1 for ; Tue, 01 Feb 2011 21:57:39 -0800 (PST) Received: by 10.227.179.77 with SMTP id bp13mr8668082wbb.226.1296626259350; Tue, 01 Feb 2011 21:57:39 -0800 (PST) Received: from [10.114.119.181] (62-50-199-254.client.stsn.net [62.50.199.254]) by mx.google.com with ESMTPS id n11sm11911138wej.43.2011.02.01.21.57.37 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 01 Feb 2011 21:57:37 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Peter Musgrave In-Reply-To: <596CBB52-4F55-4B7F-8099-D8070C34A6F0@vidyo.com> Date: Wed, 2 Feb 2011 05:57:36 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9EEB6465-626A-43B9-A653-A9B67FC01E80@magorcorp.com> <4D46ADFD.8010506@ericsson.com> <4D4801B6.7020905@ericsson.com> <596CBB52-4F55-4B7F-8099-D8070C34A6F0@vidyo.com> To: Alex Eleftheriadis X-Mailer: Apple Mail (2.1082) Cc: CLUE Subject: Re: [clue] Multiple Streams - RTP muxing? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2011 05:54:23 -0000 Great reference. I think with a few additions for CLUE specific needs = this is a very strong candidate for having a muxed audio and separate = muxed video signalled in SDP.=20 Peter Musgrave On 2011-02-01, at 2:37 PM, Alex Eleftheriadis wrote: > Certainly (and this goes beyond pure telepresence). We will need some = additional signaling tools. Check out also = draft-lennox-mmusic-sdp-source-selection-02, if you haven't already. For = future discussion. >=20 > I From peter.musgrave@magorcorp.com Tue Feb 1 22:29:36 2011 Return-Path: X-Original-To: clue@core3.amsl.com Delivered-To: clue@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F5023A6E11 for ; Tue, 1 Feb 2011 22:29:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pjqtz-XY23SU for ; Tue, 1 Feb 2011 22:29:35 -0800 (PST) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by core3.amsl.com (Postfix) with ESMTP id CC6FE3A6E88 for ; Tue, 1 Feb 2011 22:29:34 -0800 (PST) Received: by wwi17 with SMTP id 17so5658561wwi.1 for ; Tue, 01 Feb 2011 22:32:52 -0800 (PST) Received: by 10.216.54.199 with SMTP id i49mr1466445wec.63.1296628372848; Tue, 01 Feb 2011 22:32:52 -0800 (PST) Received: from [10.114.119.181] (62-50-199-254.client.stsn.net [62.50.199.254]) by mx.google.com with ESMTPS id b54sm7767287wer.21.2011.02.01.22.32.51 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 01 Feb 2011 22:32:52 -0800 (PST) From: Peter Musgrave Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 2 Feb 2011 06:32:50 +0000 Message-Id: <7F7B9A48-6A23-49BB-B3F4-9CC3D06981AA@magorcorp.com> To: CLUE CLUE Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Subject: [clue] RTP Mux - Endpoint Configuration Implications X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2011 06:29:36 -0000 Hi all,=20 If an RTP mux solution is chosen then this imposes a need for an = endpoint to receive all media of a certain type (audio or video) at the = same IP address:port.=20 Consequently this dictates endpoint architecture (an endpoint which = wants to decode a second stream on another IP in a media service type of = architecture will need to relay the data).=20 Personally I can live with one IP - since that's what my endpoints do.=20= Does this give anyone heartburn? Thanks,=20 Peter Musgrave From stephen.botzko@gmail.com Wed Feb 2 03:28:42 2011 Return-Path: X-Original-To: clue@core3.amsl.com Delivered-To: clue@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1BC43A6CBB for ; Wed, 2 Feb 2011 03:28:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.363 X-Spam-Level: X-Spam-Status: No, score=-3.363 tagged_above=-999 required=5 tests=[AWL=0.235, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pJCrIGOmGVji for ; Wed, 2 Feb 2011 03:28:41 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 992763A6BBE for ; Wed, 2 Feb 2011 03:28:41 -0800 (PST) Received: by qwi2 with SMTP id 2so8285275qwi.31 for ; Wed, 02 Feb 2011 03:32:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=P3Uq1St2FElM4fV7cIWPZ3uFBHrm8fRHpUmMFsd8g9M=; b=QkkPFPGmkQExGr/xRhvXryoGKX1gN9YzfJpM9Qno5ZXR9hGYezgNj1E+5DDX/Mw39N 4LtHQzlMGx09GCF9K/QTjBRcvh1cTijupS526gLrfu4cN+wpGdUjFpct864B/6JSXdph Nj9DdocWCOmjz8OpCFDlIIjcjVHwfDReLmivo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=uTzWl/63MpyxGbYWZYyjoT08kGBUKYxZuO9hbp/me6C8xlJgnQGOWI5hSwo6X0+MxO rayCnppDvNZ03zhZxUjvppJK7nY6G1AstYnAtCXwkc4N8OtB6C/m0J1Xn0LromXtNJPr 1yJK+JV5iyoxmciJ+46gsFeDEWClDZwTURJE8= MIME-Version: 1.0 Received: by 10.224.28.196 with SMTP id n4mr8551902qac.295.1296646320531; Wed, 02 Feb 2011 03:32:00 -0800 (PST) Received: by 10.220.128.30 with HTTP; Wed, 2 Feb 2011 03:32:00 -0800 (PST) In-Reply-To: <7F7B9A48-6A23-49BB-B3F4-9CC3D06981AA@magorcorp.com> References: <7F7B9A48-6A23-49BB-B3F4-9CC3D06981AA@magorcorp.com> Date: Wed, 2 Feb 2011 06:32:00 -0500 Message-ID: From: Stephen Botzko To: Peter Musgrave Content-Type: multipart/alternative; boundary=0015175ce0cc55a97a049b4aff69 Cc: clue@ietf.org Subject: Re: [clue] RTP Mux - Endpoint Configuration Implications X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2011 11:28:42 -0000 --0015175ce0cc55a97a049b4aff69 Content-Type: text/plain; charset=ISO-8859-1 Although our endpoints use multliple IP addresses, I am ok with a relay. One caveat - I would not want a encryption approach that requires the relay to encrypt/decrypt the full multiplex. Rather, the individual streams should be encrypted/decrypted independently. Stephen Botzko On Wed, Feb 2, 2011 at 1:32 AM, Peter Musgrave wrote: > Hi all, > > If an RTP mux solution is chosen then this imposes a need for an endpoint > to receive all media of a certain type (audio or video) at the same IP > address:port. > > Consequently this dictates endpoint architecture (an endpoint which wants > to decode a second stream on another IP in a media service type of > architecture will need to relay the data). > > Personally I can live with one IP - since that's what my endpoints do. > > Does this give anyone heartburn? > > Thanks, > > Peter Musgrave > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > --0015175ce0cc55a97a049b4aff69 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Although our endpoints use multliple IP addresses, I am ok with a relay.=A0= One caveat - I would not want a encryption approach that requires the rela= y to encrypt/decrypt the full multiplex.=A0 Rather, the individual streams = should be encrypted/decrypted independently.=A0

Stephen Botzko

On Wed, Feb 2, 2011 at= 1:32 AM, Peter Musgrave <peter.musgrave@magorcorp.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; border= -left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> Hi all,

If an RTP mux solution is chosen then this imposes a need for an endpoint t= o receive all media of a certain type (audio or video) at the same IP addre= ss:port.

Consequently this dictates endpoint architecture (an endpoint which wants t= o decode a second stream on another IP in a media service type of architect= ure will need to relay the data).

Personally I can live with one IP - since that's what my endpoints do.<= br>
Does this give anyone heartburn?

Thanks,

Peter Musgrave

_______________________________________________
clue mailing list
clue@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/clue

--0015175ce0cc55a97a049b4aff69-- From peter.musgrave@magorcorp.com Mon Feb 21 11:46:47 2011 Return-Path: X-Original-To: clue@core3.amsl.com Delivered-To: clue@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CE6E3A7127 for ; Mon, 21 Feb 2011 11:46:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.487 X-Spam-Level: X-Spam-Status: No, score=-103.487 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZHZtBGQaXHD5 for ; Mon, 21 Feb 2011 11:46:46 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 979C13A7114 for ; Mon, 21 Feb 2011 11:46:46 -0800 (PST) Received: by iyj8 with SMTP id 8so1021338iyj.31 for ; Mon, 21 Feb 2011 11:47:28 -0800 (PST) Received: by 10.42.178.10 with SMTP id bk10mr2448544icb.112.1298317648281; Mon, 21 Feb 2011 11:47:28 -0800 (PST) Received: from [192.168.1.100] ([204.237.32.134]) by mx.google.com with ESMTPS id gy41sm5458197ibb.17.2011.02.21.11.47.26 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 21 Feb 2011 11:47:27 -0800 (PST) From: Peter Musgrave Content-Type: multipart/alternative; boundary=Apple-Mail-4-35380898 Date: Mon, 21 Feb 2011 14:47:24 -0500 Message-Id: To: Magnus Westerlund Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Cc: CLUE CLUE Subject: [clue] RTP Muxing Guidance X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Feb 2011 19:46:47 -0000 --Apple-Mail-4-35380898 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Magnus,=20 I saw your post wrt muxing RTP in the context of rtc-web. = [http://www.ietf.org/mail-archive/web/dispatch/current/msg03447.html] Previously there was a thread on RTP muxing in CLUE. [see = http://www.ietf.org/mail-archive/web/clue/current/msg00061.html for the = start] You made reference to http://tools.ietf.org/html/rfc3550#section-5.2 = which governs RTP muxing.=20 If I am reading this correctly ISTM that muxing only works when all the = streams in the RTP session have the same payload type. In the case of = CLUE I am not sure if this is the case. If I understand 3550 correctly = this would then suggest that RTP muxing is not a good design choice? Regards,=20 Peter Musgrave --Apple-Mail-4-35380898 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii http://www.ietf.org/mail-archive/web/dispatch/current/msg03447.html= ]

Previously there was a thread on RTP muxing = in CLUE. [see h= ttp://www.ietf.org/mail-archive/web/clue/current/msg00061.html fo= r the start]

You made reference to http://tools.ietf.= org/html/rfc3550#section-5.2 which governs RTP = muxing. 

If I am reading this correctly = ISTM that muxing only works when all the streams in the RTP session have = the same payload type. In the case of CLUE I am not sure if this is the = case. If I understand 3550 correctly this would then suggest that RTP = muxing is not a good design = choice?

Regards, 

P= eter = Musgrave



= --Apple-Mail-4-35380898-- From ron.even.tlv@gmail.com Mon Feb 21 13:29:39 2011 Return-Path: X-Original-To: clue@core3.amsl.com Delivered-To: clue@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E2683A7188 for ; Mon, 21 Feb 2011 13:29:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rmPv-RFrr0ri for ; Mon, 21 Feb 2011 13:29:37 -0800 (PST) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by core3.amsl.com (Postfix) with ESMTP id BB8043A717B for ; Mon, 21 Feb 2011 13:29:34 -0800 (PST) Received: by bwz12 with SMTP id 12so3020846bwz.27 for ; Mon, 21 Feb 2011 13:30:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-type:x-mailer:thread-index :content-language; bh=w/Xfi1xB6J6B5Vgm4p/8jrO39RlsFKqG6J8eCBei7DQ=; b=CB+6PWQyh3WaComU4/0N3q+9KcbUQ6M2n6oqTMw9lMFeoxxI8A5HraelwNN3kDModk Y9lxLR8wYKma+KkTBjlTcV+wnaADpgQRoJDzhcLP2hVa8O9wdg4LYb19GrIi5yqcNcxI dwPM7oY+vgmJnvCVdXWekxPVmYKD6hGMf0mBk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:x-mailer:thread-index:content-language; b=D+cpvAIpyGTStQ9uyNh3s8oGcHQikVOyrq4+ROAZVrKuR+ZbF9v820WbZcLpQZPVcW IcAtvMbHO3MCzqZ8+BAxTZwGeHnpMT6N057DVs8N0NfM2A8n/Tt96QJKSJJtEXeDPKSo W9EgLWbK0ugs0mA5fUQ8H+uZJsSUH4i8KPphE= Received: by 10.204.114.72 with SMTP id d8mr1809763bkq.68.1298323816270; Mon, 21 Feb 2011 13:30:16 -0800 (PST) Received: from windows8d787f9 (bzq-79-178-22-235.red.bezeqint.net [79.178.22.235]) by mx.google.com with ESMTPS id b16sm1843717bkw.2.2011.02.21.13.30.13 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 21 Feb 2011 13:30:14 -0800 (PST) From: "Roni Even" To: "'Peter Musgrave'" , "'Magnus Westerlund'" References: In-Reply-To: Date: Mon, 21 Feb 2011 23:25:31 +0200 Message-ID: <4d62d966.5097cc0a.5f21.ffff9a41@mx.google.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_018E_01CBD21E.A3B856D0" X-Mailer: Microsoft Office Outlook 12.0 Thread-index: AcvSAC+Q6vuk91PxT2C6gxGkmFsAWAABC5oQ Content-Language: en-us Cc: 'CLUE CLUE' Subject: Re: [clue] RTP Muxing Guidance X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Feb 2011 21:29:40 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_018E_01CBD21E.A3B856D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Peter, You can RTP mux multiple video streams, just consider the issues mentioned in RFC 3550. I am not sure what is your concern Roni Even From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Peter Musgrave Sent: Monday, February 21, 2011 9:47 PM To: Magnus Westerlund Cc: CLUE CLUE Subject: [clue] RTP Muxing Guidance Hi Magnus, I saw your post wrt muxing RTP in the context of rtc-web. [http://www.ietf.org/mail-archive/web/dispatch/current/msg03447.html] Previously there was a thread on RTP muxing in CLUE. [see http://www.ietf.org/mail-archive/web/clue/current/msg00061.html for the start] You made reference to http://tools.ietf.org/html/rfc3550#section-5.2 which governs RTP muxing. If I am reading this correctly ISTM that muxing only works when all the streams in the RTP session have the same payload type. In the case of CLUE I am not sure if this is the case. If I understand 3550 correctly this would then suggest that RTP muxing is not a good design choice? Regards, Peter Musgrave ------=_NextPart_000_018E_01CBD21E.A3B856D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Peter,

You can RTP mux multiple video streams, just consider the issues = mentioned in RFC 3550.

I am not sure what is your concern

Roni Even

 

From:= = clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of = Peter Musgrave
Sent: Monday, February 21, 2011 9:47 = PM
To: Magnus Westerlund
Cc: CLUE = CLUE
Subject: [clue] RTP Muxing = Guidance

 

Hi = Magnus, 

 

I = saw your post wrt muxing RTP in the context of rtc-web. [http://www.ietf.org/mail-archive/web/dispatch/current/msg03447.html]

 

You made reference to http://tools.ietf= .org/html/rfc3550#section-5.2 which governs RTP = muxing. 

 

If I am reading this correctly ISTM that muxing only = works when all the streams in the RTP session have the same payload = type. In the case of CLUE I am not sure if this is the case. If I = understand 3550 correctly this would then suggest that RTP muxing is not = a good design choice?

 

Regards, 

 

Peter Musgrave

 

 

 

------=_NextPart_000_018E_01CBD21E.A3B856D0-- From peter.musgrave@magorcorp.com Mon Feb 21 13:55:04 2011 Return-Path: X-Original-To: clue@core3.amsl.com Delivered-To: clue@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 587753A6FF7 for ; Mon, 21 Feb 2011 13:55:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.51 X-Spam-Level: X-Spam-Status: No, score=-103.51 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nCzNNNKEoNgC for ; Mon, 21 Feb 2011 13:55:03 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id C139D3A6FEA for ; Mon, 21 Feb 2011 13:55:02 -0800 (PST) Received: by iyj8 with SMTP id 8so1134296iyj.31 for ; Mon, 21 Feb 2011 13:55:45 -0800 (PST) Received: by 10.42.224.197 with SMTP id ip5mr2509635icb.458.1298325345168; Mon, 21 Feb 2011 13:55:45 -0800 (PST) Received: from [192.168.1.100] ([204.237.32.134]) by mx.google.com with ESMTPS id u9sm5529132ibe.8.2011.02.21.13.55.43 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 21 Feb 2011 13:55:44 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-6-43078083 From: Peter Musgrave In-Reply-To: <4d62d966.5097cc0a.5f21.ffff9a41@mx.google.com> Date: Mon, 21 Feb 2011 16:55:41 -0500 Message-Id: References: <4d62d966.5097cc0a.5f21.ffff9a41@mx.google.com> To: "Roni Even" X-Mailer: Apple Mail (2.1082) Cc: 'CLUE CLUE' Subject: Re: [clue] RTP Muxing Guidance X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Feb 2011 21:55:04 -0000 --Apple-Mail-6-43078083 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii HI Roni,=20 IIUC the motivation of this section in 3550 was to dissuade re-using the = same SSRC for a stream with both audio and video content (i.e. not = relevant to CLUE).=20 However some of the text about shared sessions with the same SSRC = looked relevant to me. Perhaps I am mistaken.=20 My concern was that in the unlikely event of an SSRC collision among the = multiple video streams there would be issues similar to those as = described in 3550 5.2. I do realize this is a SHOULD NOT.=20 However, it does also say=20 "On the other hand, multiplexing multiple related sources of the same medium in one RTP session using different SSRC values is the norm for multicast sessions" And this does seem to fit with what CLUE may choose to do. Presumably = CLUE would need to guarantee SSRC uniqueness in the related sources even = when the streams have a different payload type.=20 Peter On 2011-02-21, at 4:25 PM, Roni Even wrote: > Peter, > You can RTP mux multiple video streams, just consider the issues = mentioned in RFC 3550. > I am not sure what is your concern > Roni Even > =20 > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf = Of Peter Musgrave > Sent: Monday, February 21, 2011 9:47 PM > To: Magnus Westerlund > Cc: CLUE CLUE > Subject: [clue] RTP Muxing Guidance > =20 > Hi Magnus,=20 > =20 > I saw your post wrt muxing RTP in the context of rtc-web. = [http://www.ietf.org/mail-archive/web/dispatch/current/msg03447.html] > =20 > Previously there was a thread on RTP muxing in CLUE. [see = http://www.ietf.org/mail-archive/web/clue/current/msg00061.html for the = start] > =20 > You made reference to http://tools.ietf.org/html/rfc3550#section-5.2 = which governs RTP muxing.=20 > =20 > If I am reading this correctly ISTM that muxing only works when all = the streams in the RTP session have the same payload type. In the case = of CLUE I am not sure if this is the case. If I understand 3550 = correctly this would then suggest that RTP muxing is not a good design = choice? > =20 > Regards,=20 > =20 > Peter Musgrave > =20 > =20 > =20 --Apple-Mail-6-43078083 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii HI Roni, 

IIUC the = motivation of this section in 3550 was to dissuade re-using the same = SSRC for a stream with both audio and video content (i.e. not relevant = to CLUE). 

However some of the text about = shared sessions with the same SSRC  looked relevant to me. Perhaps = I am mistaken. 

My concern was that in the = unlikely event of an SSRC collision among the multiple video streams = there would be issues similar to those as described in 3550 5.2. I do = realize this is a SHOULD NOT. 

However, it = does also say 
"On the other hand, multiplexing multiple = related sources of the same
medium in one = RTP session using different SSRC values is the norm for multicast sessions"

And this does seem =
to fit with what CLUE may choose to do. Presumably CLUE would need to =
guarantee SSRC uniqueness in the related sources even when the streams =
have a different payload type.

Peter

O= n 2011-02-21, at 4:25 PM, Roni Even wrote:

You = can RTP mux multiple video streams, just consider the issues mentioned = in RFC 3550.
I am = not sure what is your concern
Roni = Even
 clue-bounces@ietf.org [mailto:clue-bounces@ietf.org= ] On Behalf Of Peter = Musgrave
Sent: Monday, February 21, 2011 = 9:47 PM
To: Magnus = Westerlund
Cc: CLUE = CLUE
Subject: [clue] RTP Muxing = Guidance
Hi = Magnus, 
In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] RTP Muxing Guidance Thread-Index: AcvSEh7grM9zHjIXQFOsCJOuVrmWeAABEPqA References: <4d62d966.5097cc0a.5f21.ffff9a41@mx.google.com> From: "Allyn Romanow (allyn)" To: "Peter Musgrave" , "Roni Even" X-OriginalArrivalTime: 21 Feb 2011 22:29:56.0983 (UTC) FILETIME=[DE3CC870:01CBD216] Cc: CLUE CLUE Subject: Re: [clue] RTP Muxing Guidance X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Feb 2011 22:29:59 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBD216.DDEC684F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Peter, I think notion of RTP muxing of media streams with the mechanism for doing it are being intertwined, and it is being assume that the mechanism needs to be with SSRC. Probably we would find another way to demultiplex than SSRCs. That would be a large part of what the work in AVT would be- figuring out an appropriate mechanism. =20 Thanks, Allyn =20 From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Peter Musgrave Sent: Monday, February 21, 2011 1:56 PM To: Roni Even Cc: 'CLUE CLUE' Subject: Re: [clue] RTP Muxing Guidance =20 HI Roni,=20 =20 IIUC the motivation of this section in 3550 was to dissuade re-using the same SSRC for a stream with both audio and video content (i.e. not relevant to CLUE).=20 =20 However some of the text about shared sessions with the same SSRC looked relevant to me. Perhaps I am mistaken.=20 =20 My concern was that in the unlikely event of an SSRC collision among the multiple video streams there would be issues similar to those as described in 3550 5.2. I do realize this is a SHOULD NOT.=20 =20 However, it does also say=20 "On the other hand, multiplexing multiple related sources of the same medium in one RTP session using different SSRC values is the norm for multicast sessions" And this does seem to fit with what CLUE may choose to do. Presumably CLUE would need to guarantee SSRC uniqueness in the related sources even when the streams have a different payload type.=20 Peter =20 On 2011-02-21, at 4:25 PM, Roni Even wrote: Peter, You can RTP mux multiple video streams, just consider the issues mentioned in RFC 3550. I am not sure what is your concern Roni Even =20 From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Peter Musgrave Sent: Monday, February 21, 2011 9:47 PM To: Magnus Westerlund Cc: CLUE CLUE Subject: [clue] RTP Muxing Guidance =20 Hi Magnus,=20 =20 I saw your post wrt muxing RTP in the context of rtc-web. [http://www.ietf.org/mail-archive/web/dispatch/current/msg03447.html] =20 Previously there was a thread on RTP muxing in CLUE. [see http://www.ietf.org/mail-archive/web/clue/current/msg00061.html for the start] =20 You made reference to http://tools.ietf.org/html/rfc3550#section-5.2 which governs RTP muxing.=20 =20 If I am reading this correctly ISTM that muxing only works when all the streams in the RTP session have the same payload type. In the case of CLUE I am not sure if this is the case. If I understand 3550 correctly this would then suggest that RTP muxing is not a good design choice? =20 Regards,=20 =20 Peter Musgrave =20 =20 =20 =20 ------_=_NextPart_001_01CBD216.DDEC684F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Peter,

I think notion of RTP muxing of media streams with the = mechanism for doing it are being intertwined, and it is being assume that the = mechanism needs to be with SSRC. Probably we would find another way to demultiplex than = SSRCs. That would be a large part of what the work in AVT would be- figuring = out an appropriate mechanism.

 

Thanks,

Allyn

 

From:= clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of = Peter Musgrave
Sent: Monday, February 21, 2011 1:56 PM
To: Roni Even
Cc: 'CLUE CLUE'
Subject: Re: [clue] RTP Muxing Guidance

 

HI Roni, 

 

IIUC the motivation of this section in 3550 was to = dissuade re-using the same SSRC for a stream with both audio and video content = (i.e. not relevant to CLUE). 

 

However some of the text about shared sessions with = the same SSRC  looked relevant to me. Perhaps I am = mistaken. 

 

My concern was that in the unlikely event of an = SSRC collision among the multiple video streams there would be issues similar = to those as described in 3550 5.2. I do realize this is a SHOULD = NOT. 

 

However, it does also say 

"On the other = hand, multiplexing multiple related sources of the same

 &nbs=
p; medium in one RTP session using different SSRC values is the norm =
for
 &nbs=
p; multicast sessions"

And this =
does seem to fit with what CLUE may choose to do. Presumably CLUE would =
need to guarantee SSRC uniqueness in the related sources even when the =
streams have a different payload type. =

Peter

 

On 2011-02-21, at 4:25 PM, Roni Even = wrote:



Peter,

You can RTP mux multiple video streams, just consider the = issues mentioned in RFC 3550.

I am not sure what is your concern

Roni Even

 

 

Hi Magnus, 

 

 

 

You made reference to http://tools.ietf= .org/html/rfc3550#section-5.2 which governs RTP muxing. 

 

If I am reading this correctly ISTM that muxing = only works when all the streams in the RTP session have the same payload type. In = the case of CLUE I am not sure if this is the case. If I understand 3550 = correctly this would then suggest that RTP muxing is not a good design = choice?

 

Regards, 

 

Peter Musgrave

 

 

 

 

------_=_NextPart_001_01CBD216.DDEC684F-- From mary.ietf.barnes@gmail.com Sat Feb 26 11:59:27 2011 Return-Path: X-Original-To: clue@core3.amsl.com Delivered-To: clue@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C74A33A67F5 for ; Sat, 26 Feb 2011 11:59:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.498 X-Spam-Level: X-Spam-Status: No, score=-103.498 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gCIfhXUWmpjs for ; Sat, 26 Feb 2011 11:59:26 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id B34E33A67EE for ; Sat, 26 Feb 2011 11:59:26 -0800 (PST) Received: by vws6 with SMTP id 6so2498400vws.31 for ; Sat, 26 Feb 2011 12:00:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to:cc :content-type; bh=gwA9lQRQiYTQv10v9ZWjqySdpag2K7QJ5UjQXo3gZw8=; b=KnX2JqIXQ7GfMmcbsBFL9N/BBVAv7Bo8H9Wg5jNyC0KYhZQHNRQYHgha99DitNT7zp MKFWzaf/0RvplW6z3J/9twkWqy8lh2SNdPlmJNpiD/3wyKQbhkkLZkDB7VgpAkJeuOcH 1kSFyav72RGQzt3e43sPyD1tm5mxOqgwjNWYA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=wDzw6oA/DpWFQQFO3btMeIcwxoFb/9EaUOjNQrHdYfI8BahNzc+HdlD28fKdJ5W+k2 5VhSykRYk8ZCIpnYKoqfvxSXr9FCmiibVyE9wx5DOCAaPNN8ka00KuMom/rbLSZ7yu3X fJCeVm8/3YVMK3+jHbryJ3ImgGNRglwZwKAzQ= MIME-Version: 1.0 Received: by 10.52.164.168 with SMTP id yr8mr6417983vdb.16.1298750421188; Sat, 26 Feb 2011 12:00:21 -0800 (PST) Received: by 10.52.162.202 with HTTP; Sat, 26 Feb 2011 12:00:21 -0800 (PST) Date: Sat, 26 Feb 2011 14:00:21 -0600 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=bcaec53f95c581c077049d34e560 Subject: [clue] CLUE - scheduled for IETF 80 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Feb 2011 19:59:28 -0000 --bcaec53f95c581c077049d34e560 Content-Type: text/plain; charset=ISO-8859-1 Hi folks, The IETF-80 WG session has been scheduled as follows: ---------------------------------------------- CLUE Session 1 (2 hours) Wednesday, Afternoon Session I 1300-1500 Room Name: Congress Hall II ---------------------------------------------- As always, the date and time can change and WG sessions can be scheduled through Friday afternoon. As a reminder, the draft deadlines are as follows: - *2011-03-07 (Monday):* Internet Draft Cut-off for initial document (-00) submission by 17:00 PT (01:00 Tuesday, March 8 UTC), upload using IETF ID Submission Tool . - *2011-03-14 (Monday):* Internet Draft final submission cut-off by 17:00 PT (01:00 Tuesday, March 15 UTC), upload using IETF ID Submission Tool . At this time, the chairs are aware of an update to the use case document, as a well as a new individual requirements document, both of which should be submitted soon. If you plan on submitting a document, please let the chairs know ASAP. A draft agenda will be posted on or before March 16th. Please note that there needs to be a fair amount of WG discussion to justify agenda time for the various documents. So, the sooner documents are submitted the better. Regards, Mary. CLUE WG co-chair --bcaec53f95c581c077049d34e560 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi folks,

The IETF-80 WG session has been scheduled as f= ollows:

---------------------------------= -------------
CLUE Session 1 (2 hours)
Wednesday, Afternoon Session I 1300-1500
Room Name: Congress Hall II
----------------------------------------------

As always, the date and time can c= hange and WG sessions can be scheduled through Friday afternoon.

As a reminder, the draft deadlines are= as follows:

  • 2011-03-07 (Monday= ):=A0Internet Draft Cut-off for initial document (-00) submission = by 17:00 PT (01:00 Tuesday, March 8 UTC), upload using=A0IETF ID Submission Tool.
  • 2011-03-14 (Monday= ):=A0Internet Draft final submission cut-off by 17:00 PT (01:00 Tu= esday, March 15 UTC), upload using=A0IETF ID Submission Tool.


At this time, the chairs = are aware of an update to the use case document, as a well as a new individ= ual requirements document, both of which should be submitted soon. =A0If yo= u plan on submitting a document, please let the chairs know ASAP. =A0A draf= t agenda will be posted on or before =A0March 16th. =A0

Please note= that there needs to be a fair amount of WG discussion to justify agenda ti= me for the various documents. =A0So, the sooner documents are submitted the= better.=A0

Regards,
Mary.
CLUE WG= co-chair
--bcaec53f95c581c077049d34e560-- From magnus.westerlund@ericsson.com Mon Feb 28 08:47:50 2011 Return-Path: X-Original-To: clue@core3.amsl.com Delivered-To: clue@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F53B3A6A10 for ; Mon, 28 Feb 2011 08:47:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.401 X-Spam-Level: X-Spam-Status: No, score=-106.401 tagged_above=-999 required=5 tests=[AWL=0.198, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eaTzx7E1+w3l for ; Mon, 28 Feb 2011 08:47:49 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id C60393A6A04 for ; Mon, 28 Feb 2011 08:47:48 -0800 (PST) X-AuditID: c1b4fb3d-b7bbbae000005311-c4-4d6bd1f0bd88 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 45.97.21265.0F1DB6D4; Mon, 28 Feb 2011 17:48:48 +0100 (CET) Received: from [147.214.183.8] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.2.234.1; Mon, 28 Feb 2011 17:48:48 +0100 Message-ID: <4D6BD1F0.5080106@ericsson.com> Date: Mon, 28 Feb 2011 17:48:48 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; sv-SE; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Allyn Romanow (allyn)" References: <4d62d966.5097cc0a.5f21.ffff9a41@mx.google.com> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC039D71DF@xmb-sjc-221.amer.cisco.com> In-Reply-To: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC039D71DF@xmb-sjc-221.amer.cisco.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: CLUE CLUE Subject: Re: [clue] RTP Muxing Guidance X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2011 16:47:50 -0000 Allyn Romanow (allyn) skrev 2011-02-21 23:29: > Hi Peter, > > I think notion of RTP muxing of media streams with the mechanism for > doing it are being intertwined, and it is being assume that the > mechanism needs to be with SSRC. Probably we would find another way to > demultiplex than SSRCs. That would be a large part of what the work in > AVT would be- figuring out an appropriate mechanism. RTP sessions are intended to separate media streams for different purposes and kind. Here is something I have written that will show up next week in an Internet draft. Warning for still being a non polished text. RTP has three fundamental points of multiplexing. The first one is the RTP session, which is used to separate media of different kind or purpose. Such as Audio and Video, or the document camera and the speaker camera in video conference. This is multiplexing point that doesn't have an identifier within the RTP protocol, instead it is relied on the lower layer to separate the different RTP session. Thus the most common RTP session separation is different RTP port number, but also address or other identifiers maybe used to achieve this separation. The second multiplexing point is the SSRC that separates different sources of media within a single RTP session. The third is the RTP Payload type, which identifies how the media from a particular source are encoded. These multiplexing points area fundamental part of the design of RTP and is discussed in Section 5.2 of [RFC3550]. From that list the ones that are directly related to the importance of the RTP session as concept are 4 and 5 (from RFC 3550): "4. An RTP mixer would not be able to combine interleaved streams of incompatible media into one stream." "5. Carrying multiple media in one RTP session precludes: the use of different network paths or network resource allocations if appropriate; reception of a subset of the media if desired, for example just audio if video would exceed the available bandwidth; and receiver implementations that use separate processes for the different media, whereas using separate RTP sessions permits either single- or multiple-process implementations." Point 4, has to do with media of different kind or purpose. The processing that can happen in an RTP mixer, translator or in an end- point is dependent on the purpose and media type of the stream. Thus there is an importance of separating such streams from each other. This could of course be achieved by other methods, like tagging SSRC values with their purpose, however there are reasons why this was not chosen. First of all it is not the simple solution, as this require additional signalling, and possibly synchronization between session peers. In addition there is the issue point 5 raises. Point 5 has to do with enabling quality of service or traffic engineering between the media flows in different RTP sessions. By using different transport layer ports, QoS mechanism that are capable of operating on the 5-tuple (Source address, port, destination address, port, and protocol) can be used without modification on RTP. Due to these design principle implementors of various services or applications using RTP has not violated this model. If one would chose to violate it today one would not achieve simple interoperability with existing services, applications and implementations. Lets assume one overloads multiple RTP sessions into one by tagging the SSRC to belong to different purposes. If one would gateway that design into a legacy system, then there would be a significant issue with SSRC collision. This as the legacy system would not know about the need to avoid using the same SSRC in the different RTP sessions. There are also various RTP mechanism that has the potential for issues if one don't have a clear separation of RTP sessions: Scalabilty: RTP was built with media scalability in consideration. The simplest way of achieving separation between different scalability layers are placing them in different RTP sessions, and using the same SSRC and CNAME in each session to bind them together. This is most commonly done in multicast, but gatewaying of such a session would then require more alterations and likely stateful translation. RTP Retransmission in Session Multiplexing mode: RTP Retransmission [RFC4588] does have a mode for session multiplexing. FEC: The "An RTP Payload Format for Generic Forward Error Correction" [RFC2733] and its update [RFC5109] can only be used on media formats that produce RTP packets that are larger than half the MTU if the FEC flow and media flow being protected are in different RTP sessions. This is because the SSRC value of the original flow is recovered from the FEC packets SSRC field. RTCP behavior also becomes a factor in why overloading RTP sessions is problematic. The extension mechanisms used in RTCP depends on the media streams. For example the Extended RTCP report block for VoIP is of suitable for conversational audio, but clearly not useful for Video. This has three impacts, either one get unusable reports if they are generated for streams where there are little purpose. This is maybe less likely for the VoIP report, but for example the more detailed media agnostic reports it may occur. It otherwise makes the implementation of RTCP more complex as the SSRC purpose tagging needs not only to be one the media side, but also on the RTCP reporting. Also the RTCP reporting interval and transmission scheduling will be affected. As a conclusion not ensuring that RTP sessions are used for its intended purpose as a multiplexing point does violate the RTP design philosophy. It prevents the usage of certain RTP extensions. It will require additional extensions to function and will significantly increase the complexity of the implementation. At the same time it will significantly reduce the interoperability with current implementations. So read and consider and lets continue the discussion on what is appropriate and what is not when it comes to what one put in a single RTP session compared to using multiple ones. 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: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From allyn@cisco.com Mon Feb 28 15:18:49 2011 Return-Path: X-Original-To: clue@core3.amsl.com Delivered-To: clue@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 456EF3A6836 for ; Mon, 28 Feb 2011 15:18:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 923EM3K8hdMd for ; Mon, 28 Feb 2011 15:18:47 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id D390F3A6835 for ; Mon, 28 Feb 2011 15:18:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=allyn@cisco.com; l=7850; q=dns/txt; s=iport; t=1298935189; x=1300144789; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=tOwo7gISXXlR5smBMWlbdZrsgWIV16zjM7UPKMEuZwk=; b=Aqf3RKEbCMK3kCA5lJvDgOg8AnYCbX77tmRsyJABKUTP0NieSpeySVrl t8jeMEcfj2hAiUSXsiqgDXZ6yMdOz7POsn1uMKOO2d5F3JTdarUdgLj00 WqMhsuEHrVfvrK9OVcep+NyZ8l9K68X7YuraCCb0qxU+Vfy54pMGefDjb U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvoAADO8a02rR7Hu/2dsb2JhbACXc45UdJ9vm2MChV8EhRKKUQ X-IronPort-AV: E=Sophos;i="4.62,243,1297036800"; d="scan'208";a="266718319" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-4.cisco.com with ESMTP; 28 Feb 2011 23:19:41 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id p1SNJeco011551; Mon, 28 Feb 2011 23:19:41 GMT Received: from xmb-sjc-221.amer.cisco.com ([128.107.191.80]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 28 Feb 2011 15:19:39 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 28 Feb 2011 15:19:36 -0800 Message-ID: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC03B19668@xmb-sjc-221.amer.cisco.com> In-Reply-To: <4D6BD1F0.5080106@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] RTP Muxing Guidance Thread-Index: AcvXZ2Sdx+l46vwtSx275qOafKDKMAANmung References: <4d62d966.5097cc0a.5f21.ffff9a41@mx.google.com> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC039D71DF@xmb-sjc-221.amer.cisco.com> <4D6BD1F0.5080106@ericsson.com> From: "Allyn Romanow (allyn)" To: "Magnus Westerlund" X-OriginalArrivalTime: 28 Feb 2011 23:19:39.0378 (UTC) FILETIME=[F8C66520:01CBD79D] Cc: CLUE CLUE Subject: Re: [clue] RTP Muxing Guidance X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2011 23:18:49 -0000 Hi Magnus, I wanted to let you know that I saw your email which brings up good = points. I'm tied up for a couple of days, so I'll be able to respond = later in the week. Best regards, Allyn > -----Original Message----- > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > Sent: Monday, February 28, 2011 8:49 AM > To: Allyn Romanow (allyn) > Cc: Peter Musgrave; Roni Even; CLUE CLUE > Subject: Re: [clue] RTP Muxing Guidance >=20 > Allyn Romanow (allyn) skrev 2011-02-21 23:29: > > Hi Peter, > > > > I think notion of RTP muxing of media streams with the mechanism for > > doing it are being intertwined, and it is being assume that the > > mechanism needs to be with SSRC. Probably we would find another way > to > > demultiplex than SSRCs. That would be a large part of what the work > in > > AVT would be- figuring out an appropriate mechanism. >=20 > RTP sessions are intended to separate media streams for different > purposes and kind. Here is something I have written that will show up > next week in an Internet draft. Warning for still being a non polished > text. >=20 > RTP has three fundamental points of multiplexing. The first one is > the RTP session, which is used to separate media of different kind > or > purpose. Such as Audio and Video, or the document camera and the > speaker camera in video conference. This is multiplexing point = that > doesn't have an identifier within the RTP protocol, instead it is > relied on the lower layer to separate the different RTP session. > Thus the most common RTP session separation is different RTP port > number, but also address or other identifiers maybe used to achieve > this separation. The second multiplexing point is the SSRC that > separates different sources of media within a single RTP session. > The third is the RTP Payload type, which identifies how the media > from a particular source are encoded. >=20 > These multiplexing points area fundamental part of the design of = RTP > and is discussed in Section 5.2 of [RFC3550]. From that list the > ones that are directly related to the importance of the RTP session > as concept are 4 and 5 (from RFC 3550): >=20 > "4. An RTP mixer would not be able to combine interleaved streams > of > incompatible media into one stream." >=20 > "5. Carrying multiple media in one RTP session precludes: the use > of > different network paths or network resource allocations if > appropriate; reception of a subset of the media if desired, for > example just audio if video would exceed the available = bandwidth; > and receiver implementations that use separate processes for the > different media, whereas using separate RTP sessions permits > either single- or multiple-process implementations." >=20 > Point 4, has to do with media of different kind or purpose. The > processing that can happen in an RTP mixer, translator or in an = end- > point is dependent on the purpose and media type of the stream. > Thus > there is an importance of separating such streams from each other. > This could of course be achieved by other methods, like tagging = SSRC > values with their purpose, however there are reasons why this was > not > chosen. First of all it is not the simple solution, as this = require > additional signalling, and possibly synchronization between session > peers. In addition there is the issue point 5 raises. >=20 > Point 5 has to do with enabling quality of service or traffic > engineering between the media flows in different RTP sessions. By > using different transport layer ports, QoS mechanism that are > capable > of operating on the 5-tuple (Source address, port, destination > address, port, and protocol) can be used without modification on > RTP. >=20 > Due to these design principle implementors of various services or > applications using RTP has not violated this model. If one would > chose to violate it today one would not achieve simple > interoperability with existing services, applications and > implementations. Lets assume one overloads multiple RTP sessions > into one by tagging the SSRC to belong to different purposes. If > one > would gateway that design into a legacy system, then there would be > a > significant issue with SSRC collision. This as the legacy system > would not know about the need to avoid using the same SSRC in the > different RTP sessions. >=20 > There are also various RTP mechanism that has the potential for > issues if one don't have a clear separation of RTP sessions: >=20 > Scalabilty: RTP was built with media scalability in consideration. > The simplest way of achieving separation between different > scalability layers are placing them in different RTP sessions, > and > using the same SSRC and CNAME in each session to bind them > together. This is most commonly done in multicast, but > gatewaying of such a session would then require more alterations > and likely stateful translation. >=20 > RTP Retransmission in Session Multiplexing mode: RTP = Retransmission > [RFC4588] does have a mode for session multiplexing. >=20 > FEC: The "An RTP Payload Format for Generic Forward Error > Correction" [RFC2733] and its update [RFC5109] can only be used > on > media formats that produce RTP packets that are larger than half > the MTU if the FEC flow and media flow being protected are in > different RTP sessions. This is because the SSRC value of the > original flow is recovered from the FEC packets SSRC field. >=20 > RTCP behavior also becomes a factor in why overloading RTP sessions > is problematic. The extension mechanisms used in RTCP depends on > the > media streams. For example the Extended RTCP report block for VoIP > is of suitable for conversational audio, but clearly not useful for > Video. This has three impacts, either one get unusable reports if > they are generated for streams where there are little purpose. = This > is maybe less likely for the VoIP report, but for example the more > detailed media agnostic reports it may occur. It otherwise makes > the implementation of RTCP more complex as the SSRC purpose tagging > needs not only to be one the media side, but also on the RTCP > reporting. Also the RTCP reporting interval and transmission > scheduling will be affected. >=20 > As a conclusion not ensuring that RTP sessions are used for its > intended purpose as a multiplexing point does violate the RTP = design > philosophy. It prevents the usage of certain RTP extensions. It > will > require additional extensions to function and will significantly > increase the complexity of the implementation. At the same time it > will significantly reduce the interoperability with current > implementations. >=20 >=20 > So read and consider and lets continue the discussion on what is > appropriate and what is not when it comes to what one put in a single > RTP session compared to using multiple ones. >=20 > Cheers >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ----------------------------------------------------------------------