From ron.even.tlv@gmail.com Thu Jan 6 02:10: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 42C7F3A6CE0 for ; Thu, 6 Jan 2011 02:10:36 -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=[AWL=-0.000, 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 g9yh+4d2l3xn for ; Thu, 6 Jan 2011 02:10:30 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id B25D13A6CC8 for ; Thu, 6 Jan 2011 02:10:26 -0800 (PST) Received: by wwa36 with SMTP id 36so16274021wwa.13 for ; Thu, 06 Jan 2011 02:12:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:references :in-reply-to:subject:date:message-id:mime-version:content-type :x-mailer:thread-index:content-language; bh=H7PHPcfIf6KGSfrZ17684CcekXeSkzTK6sls6ID19Jo=; b=CcKWRw7AvBj3SDRnwJa4FxKQaKMPm8zmSjF1gzr/UUU29ZRld9hq4fHedx1+9/NrzT gzdsOQyPjNVGAeXPU3PAZw4eL09M+GD0JJT3Mtd8CJP7F9j8lTuYamlZrUu34gK81bER cRW15623t+Jrl8fvBAKjkwNSt7nFvXGe9Vnbc= 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=L9POopwIh2u4tbWb8Eh3cOoyaDxADltbS3iMUjs8zmQcr/LA8TmeA/HtBwbVTtkb/n ARhG3WsOXWz6J+URAr1TB+o5s9SvkmvLAFwogiesfkGkcVPCKej5lkKd3Bfv0NIji1dc AsGHn5dGbT5ax4HefZKGa2No65Ci+qO+JRGMU= Received: by 10.227.151.193 with SMTP id d1mr9949267wbw.201.1294308753019; Thu, 06 Jan 2011 02:12:33 -0800 (PST) Received: from windows8d787f9 (bzq-79-178-17-26.red.bezeqint.net [79.178.17.26]) by mx.google.com with ESMTPS id r38sm11678664weq.23.2011.01.06.02.12.30 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 06 Jan 2011 02:12:31 -0800 (PST) From: "Roni Even" To: "'Allyn Romanow \(allyn\)'" , "'Peter Musgrave'" References: <928969B1-F60B-47B8-A526-676E86BA7061@magorcorp.com><62F4714D-7819-4BBE-A588-9BE3FADBC001@magorcorp.com><44C6B6B2D0CF424AA90B6055548D7A61A76B37EA@CRPMBOXPRD01.polycom.com><9AD62F43-2E19-48F6-8306-F8E62E0514BC@magorcorp.com> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC030F4D07@xmb-sjc-221.amer.cisco.com> In-Reply-To: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC030F4D07@xmb-sjc-221.amer.cisco.com> Date: Thu, 6 Jan 2011 12:09:07 +0200 Message-ID: <4d25958f.26ead80a.36de.ffffa9d8@mx.google.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01F1_01CBAD9A.86279160" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcuTJVM5UmTBXzRBROSJqsUtiVmgfAAEsATQBpI5j8A= Content-Language: en-us Cc: clue@ietf.org Subject: Re: [clue] [maitai] Roles of Sender and Receiver 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: Thu, 06 Jan 2011 10:10:36 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_01F1_01CBAD9A.86279160 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Allyn, I think that are current view as described in the use cases are based on receiver composed. We describe the streams that can be sent but are not discussing the composition at the receiver. If the sender will decide which streams to send it may need to know not only the number of monitors on the receiver but also if the receiver can compose multiple streams to one display or have some PIP capabilities. I think that one such example of sender decision base on receiver capability is "send me only the stream from the camera of the active speaker". This is not a simple selection like the current offer answer. I think that if we go this way (sender composed) it may require to be able to define many different policies that may be requested by the receiver. Roni From: maitai-bounces@ietf.org [mailto:maitai-bounces@ietf.org] On Behalf Of Allyn Romanow (allyn) Sent: Saturday, December 04, 2010 12:47 AM To: Peter Musgrave Cc: maitai@ietf.org Subject: Re: [maitai] Roles of Sender and Receiver Hi Peter, I agree with Marshall's later comment that "we have to accommodate both models". It seems to me that different systems may work differently - some may use a subscription model, others can have it pre-set that either the sender (including MCU), or receiver (as in current Cisco system) may decide how to do the layout. In the primary spec that we are developing, we just need to be able to give coherent information for whichever implementation policy is being followed. So, we have to check that our descriptive model works for different implementation methods. The second aspect of the charter is to see what extensions in our protocols may be necessary to be able to carry out one or another policy. But for the spec that we are doing to describe the relationships between multiple streams so that they can be reasonably rendered, I think we need to have that description work for any of the composition models (meaning sender composed or receiver composed). What do you think? Allyn ---------- From: Peter Musgrave Date: Thu, Dec 2, 2010 at 2:02 PM To: "Mike Hammer (hmmr)" Cc: maitai@ietf.org I think this is actually a different, very interesting issue. This speaks to control DURING the call and the need for that to be dynamic. I completely agree - but as understand the charter it's out of scope...although I think it is inevitable that we will need to look at what exists (BFCP, conference event etc.) and determine if it can be used or start to define something new. This might be subverted by sending all and letting the receiver take them on and off hold quickly...clunky but avoid protocol work. My specific question relates to the initial setup where I have two 3 display, 3 camera systems from different vendors. Who decides which stream goes where? Sender or receiver? Peter ---------- ------=_NextPart_000_01F1_01CBAD9A.86279160 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Allyn,

I think that are current view as described in the use cases are based = on receiver composed. We describe the streams that can be sent but are = not discussing the composition at the receiver. If the sender will = decide which streams to send it may need to know not only the number of = monitors on the receiver but also if the receiver can compose multiple = streams to one display or have some PIP = capabilities.

I think that one such example of sender decision base on receiver = capability is "send me only the stream from the camera of the = active speaker". This is not a simple selection like the current = offer answer. I think that if we go this way (sender composed) it may = require to be able to define many different policies that may be = requested by the receiver.

 

Roni

 

From:= = maitai-bounces@ietf.org [mailto:maitai-bounces@ietf.org] On Behalf Of = Allyn Romanow (allyn)
Sent: Saturday, December 04, 2010 = 12:47 AM
To: Peter Musgrave
Cc: = maitai@ietf.org
Subject: Re: [maitai] Roles of Sender and = Receiver

 

Hi Peter,

 

I agree with Marshall’s later comment that “we = have to accommodate both models”.

It seems to me that different systems may work differently – = some may use a subscription model, others can have it pre-set that = either the sender (including MCU), or receiver (as in current Cisco = system) may decide how to do the layout. In the primary spec that we are = developing, we just need to be able to give coherent information for = whichever implementation policy is being followed. So, we have to check = that our descriptive model works for different implementation = methods.

 

The second aspect of the charter is to see what extensions  in = our protocols may be necessary to be able to carry out one or another = policy.  But for the spec that we are doing to describe the = relationships between multiple streams so that they can be reasonably = rendered, I think we need to have that description work for any of the = composition models (meaning sender composed or receiver = composed).

 

What do you think?

 

Allyn

 ----------
From: Peter Musgrave <peter.musgrave@magorcorp.com= >
Date: Thu, Dec 2, 2010 at = 2:02 PM
To: "Mike Hammer = (hmmr)" <hmmr@cisco.com>
Cc: maitai@ietf.org


I = think this is actually a different, very interesting issue. This speaks = to control DURING the call and the need for that to be dynamic. I = completely agree - but as understand the charter it's out of = scope...although I think it is inevitable that we will need to look at = what exists (BFCP, conference event etc.) and determine if it can be = used or start to define something new.

This might be subverted by = sending all and letting the receiver take them on and off hold = quickly...clunky but avoid protocol work.

My specific question = relates to the initial setup where I have two 3 display, 3 camera = systems from different vendors. Who decides which stream goes where? = Sender or receiver?

Peter


----------
 

 

------=_NextPart_000_01F1_01CBAD9A.86279160-- From ron.even.tlv@gmail.com Thu Jan 6 02:10:46 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 B8F683A6EFC for ; Thu, 6 Jan 2011 02:10:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, 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 NKG3+x-l1aXX for ; Thu, 6 Jan 2011 02:10:46 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 57E133A6DF1 for ; Thu, 6 Jan 2011 02:10:46 -0800 (PST) Received: by wyf23 with SMTP id 23so16968628wyf.31 for ; Thu, 06 Jan 2011 02:12:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:references :in-reply-to:subject:date:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:thread-index:content-language; bh=sIkhb2eZQOvyJoUOMv0NA5Z21WabV55Qd1v28K+77zU=; b=keFrb/ePuWJ4A8s3m5PL4Smk5TduJP8wkq95czSpMtvlwrHR4Ro35vZReqIoWiQxOk YpV7yCNMyij18wmZi8O1g0dHbxNWs6cv0xp+P+v7fyvVmmTr3HtQbutsiB/mDOzIC825 sIJnmHEoMolTUW3H1WPOWk8SRpm4G2N0t8cPo= 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:content-transfer-encoding:x-mailer :thread-index:content-language; b=EMlyQKiqY4VPdTGU4dKsMfd5OFIqcomdk1HwSNtL9aW5CUEIhO8nXFo9+fE4908Ubb yAhSrjhpWWFrGtImP8kz5f+SZ02IR/9LkMGepi4dx/yXd96/6NLs76z/W3oTai+Dt30B ANUwWKrypv//LSeAO0oEy+B7hhwcGh98ToWPg= Received: by 10.227.98.94 with SMTP id p30mr6032545wbn.152.1294308772799; Thu, 06 Jan 2011 02:12:52 -0800 (PST) Received: from windows8d787f9 (bzq-79-178-17-26.red.bezeqint.net [79.178.17.26]) by mx.google.com with ESMTPS id i80sm11679862wej.4.2011.01.06.02.12.50 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 06 Jan 2011 02:12:51 -0800 (PST) From: "Roni Even" To: "'Peter Musgrave'" , "'Mike Hammer \(hmmr\)'" References: <928969B1-F60B-47B8-A526-676E86BA7061@magorcorp.com><4CF9975D.4060903@cisco.com><9ECCF01B52E7AB408A7EB853526421410242061C@ftrdmel0.rd.francetelecom.fr> <89B356FD-0D42-4C8B-B48F-7D70FF4E6E8F@magorcorp.com> <95E0BE2D-41B0-4FA4-9634-05D2141186D1@magorcorp.com> In-Reply-To: <95E0BE2D-41B0-4FA4-9634-05D2141186D1@magorcorp.com> Date: Thu, 6 Jan 2011 12:09:28 +0200 Message-ID: <4d2595a3.e68ed80a.5680.ffffa3fb@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcuWINZhVTtHZEtCQQqoUexwIVAVYwXZ6GAA Content-Language: en-us Cc: clue@ietf.org Subject: Re: [clue] [maitai] Roles of Sender and Receiver 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: Thu, 06 Jan 2011 10:10:46 -0000 Hi, I think this is an important point. We may need to look at the changes during the call which may be temporary and I do not think that using offer answer for it will be the optimal solution. Roni > -----Original Message----- > From: maitai-bounces@ietf.org [mailto:maitai-bounces@ietf.org] On > Behalf Of Peter Musgrave > Sent: Tuesday, December 07, 2010 5:10 PM > To: Mike Hammer (hmmr) > Cc: maitai@ietf.org > Subject: Re: [maitai] Roles of Sender and Receiver > > Nope. > > I think there are several bridges. The first is the initial call setup > and mapping streams. The second is adding/removing/making changes as > the meeting proceeds and the need for specific stream content > changes... > > Peter > > On 2010-12-07, at 10:01 AM, Mike Hammer (hmmr) wrote: > > > Better to use a new attribute than overload an existing attribute. > > > > But, this also assumes we are using SDP and SIP to provide dynamic > > controls during call. > > Have we crossed that bridge yet? > > > > Mike > > > > > > -----Original Message----- > > From: maitai-bounces@ietf.org [mailto:maitai-bounces@ietf.org] On > Behalf > > Of Peter Musgrave > > Sent: Tuesday, December 07, 2010 6:07 AM > > To: bruno.chatras@orange-ftgroup.com > > Cc: maitai@ietf.org > > Subject: Re: [maitai] Roles of Sender and Receiver > > > > I think this causes confusion with hold/resume. I can have a camera > and > > display but choose not to receive your video temporarily as I e.g. > use > > the display to look at something else. > > > > Hence I don't see it a suitable for describing the static endpoint > > physical configuration. > > > > In principle a new SDP attribute could be used (e.g. a=device:camera) > > but this will cause all kinds of backwards compatibility issues with > > calls to devices which do not understand this. I suspect some use of > the > > SDP grouping framework might come into play here... > > > > Peter > > > > > > On 2010-12-07, at 3:49 AM, wrote: > > > >>> > >>> In fact in the first exchange we also need to provide some > >>> information about media asymmetry (e.g. I may have three > >>> screens, but 4 cameras or three screens and two cameras). so > >>> my video m lines do not necessarily imply anything my ability > >>> to send that many videos.... > >>> > >> > >> Why can't we use one m= line per unidirectional stream and use > >> a=sendonly/a=recvonly to discrimate between screens and cameras? > > > > _______________________________________________ > > maitai mailing list > > maitai@ietf.org > > https://www.ietf.org/mailman/listinfo/maitai > > _______________________________________________ > maitai mailing list > maitai@ietf.org > https://www.ietf.org/mailman/listinfo/maitai From allyn@cisco.com Thu Jan 6 13:07: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 CDF193A6D05 for ; Thu, 6 Jan 2011 13:07:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.506 X-Spam-Level: X-Spam-Status: No, score=-10.506 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 ajYhg+SNbaM4 for ; Thu, 6 Jan 2011 13:07:41 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 35A7B3A6CEC for ; Thu, 6 Jan 2011 13:07:41 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AikFALO+JU2rR7Hu/2dsb2JhbACCKaF2c6VQmCmFTASEZ4lFgnA Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 06 Jan 2011 21:09:47 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id p06L9iTk010377; Thu, 6 Jan 2011 21:09:47 GMT Received: from xmb-sjc-221.amer.cisco.com ([128.107.191.80]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 6 Jan 2011 13:09:47 -0800 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_01CBADE6.0C2A7CA5" Date: Thu, 6 Jan 2011 13:09:45 -0800 Message-ID: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC034A3EFC@xmb-sjc-221.amer.cisco.com> In-Reply-To: <4d25893f.c89cd80a.3f70.ffffa0a2@mx.google.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [maitai] Roles of Sender and Receiver Thread-Index: AcuTJVM5UmTBXzRBROSJqsUtiVmgfAAEsATQBpI5j8AAGS94sA== References: <928969B1-F60B-47B8-A526-676E86BA7061@magorcorp.com><62F4714D-7819-4BBE-A588-9BE3FADBC001@magorcorp.com><44C6B6B2D0CF424AA90B6055548D7A61A76B37EA@CRPMBOXPRD01.polycom.com><9AD62F43-2E19-48F6-8306-F8E62E0514BC@magorcorp.com> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC030F4D07@xmb-sjc-221.amer.cisco.com> <4d25893f.c89cd80a.3f70.ffffa0a2@mx.google.com> From: "Allyn Romanow (allyn)" To: "Roni Even" , "Peter Musgrave" X-OriginalArrivalTime: 06 Jan 2011 21:09:47.0318 (UTC) FILETIME=[0C73A560:01CBADE6] Cc: clue@ietf.org Subject: Re: [clue] [maitai] Roles of Sender and Receiver 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: Thu, 06 Jan 2011 21:07:47 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBADE6.0C2A7CA5 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Roni, Yes, I agree with you. I was just looking at how to update the use cases to reflect this, as I believe we have to encompass both receiver based layouts, which probably include subscription, and sender based layouts, in which the sender needs to know something about the receiver's display capabilities. =20 Best regards, Allyn =20 From: Roni Even [mailto:ron.even.tlv@gmail.com]=20 Sent: Thursday, January 06, 2011 1:17 AM To: Allyn Romanow (allyn); 'Peter Musgrave' Cc: maitai@ietf.org Subject: RE: [maitai] Roles of Sender and Receiver =20 Hi Allyn, I think that are current view as described in the use cases are based on receiver composed. We describe the streams that can be sent but are not discussing the composition at the receiver. If the sender will decide which streams to send it may need to know not only the number of monitors on the receiver but also if the receiver can compose multiple streams to one display or have some PIP capabilities. I think that one such example of sender decision base on receiver capability is "send me only the stream from the camera of the active speaker". This is not a simple selection like the current offer answer. I think that if we go this way (sender composed) it may require to be able to define many different policies that may be requested by the receiver. =20 Roni =20 From: maitai-bounces@ietf.org [mailto:maitai-bounces@ietf.org] On Behalf Of Allyn Romanow (allyn) Sent: Saturday, December 04, 2010 12:47 AM To: Peter Musgrave Cc: maitai@ietf.org Subject: Re: [maitai] Roles of Sender and Receiver =20 Hi Peter, =20 I agree with Marshall's later comment that "we have to accommodate both models".=20 It seems to me that different systems may work differently - some may use a subscription model, others can have it pre-set that either the sender (including MCU), or receiver (as in current Cisco system) may decide how to do the layout. In the primary spec that we are developing, we just need to be able to give coherent information for whichever implementation policy is being followed. So, we have to check that our descriptive model works for different implementation methods. =20 The second aspect of the charter is to see what extensions in our protocols may be necessary to be able to carry out one or another policy. But for the spec that we are doing to describe the relationships between multiple streams so that they can be reasonably rendered, I think we need to have that description work for any of the composition models (meaning sender composed or receiver composed). =20 What do you think? =20 Allyn ---------- From: Peter Musgrave Date: Thu, Dec 2, 2010 at 2:02 PM To: "Mike Hammer (hmmr)" Cc: maitai@ietf.org I think this is actually a different, very interesting issue. This speaks to control DURING the call and the need for that to be dynamic. I completely agree - but as understand the charter it's out of scope...although I think it is inevitable that we will need to look at what exists (BFCP, conference event etc.) and determine if it can be used or start to define something new. This might be subverted by sending all and letting the receiver take them on and off hold quickly...clunky but avoid protocol work. My specific question relates to the initial setup where I have two 3 display, 3 camera systems from different vendors. Who decides which stream goes where? Sender or receiver? Peter ---------- =20 =20 ------_=_NextPart_001_01CBADE6.0C2A7CA5 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Roni,

Yes, I agree with you. I was just looking at how to = update the use cases to reflect this, as I believe we have to encompass both = receiver based layouts, which probably include subscription, and sender based = layouts, in which the sender needs to know something about the receiver’s = display capabilities.

 

Best regards,

Allyn

 

From:= Roni Even [mailto:ron.even.tlv@gmail.com]
Sent: Thursday, January 06, 2011 1:17 AM
To: Allyn Romanow (allyn); 'Peter Musgrave'
Cc: maitai@ietf.org
Subject: RE: [maitai] Roles of Sender and = Receiver

 

Hi Allyn,

I think that are current view as described in the use = cases are based on receiver composed. We describe the streams that can be sent but = are not discussing the composition at the receiver. If the sender will = decide which streams to send it may need to know not only the number of monitors on = the receiver but also if the receiver can compose multiple streams to one = display or have some PIP capabilities.

I think that one such example of sender decision base on receiver capability is "send me only the stream from the camera of = the active speaker". This is not a simple selection like the current = offer answer. I think that if we go this way (sender composed) it may require = to be able to define many different policies that may be requested by the = receiver.

 

Roni

 

From:= maitai-bounces@ietf.org [mailto:maitai-bounces@ietf.org] On Behalf Of = Allyn Romanow (allyn)
Sent: Saturday, December 04, 2010 12:47 AM
To: Peter Musgrave
Cc: maitai@ietf.org
Subject: Re: [maitai] Roles of Sender and = Receiver

 

Hi Peter,

 

I agree with Marshall’s later comment that = “we have to accommodate both models”.

It seems to me that different systems may work = differently – some may use a subscription model, others can have it pre-set = that either the sender (including MCU), or receiver (as in current Cisco = system) may decide how to do the layout. In the primary spec that we are developing, = we just need to be able to give coherent information for whichever = implementation policy is being followed. So, we have to check that our descriptive = model works for different implementation methods.

 

The second aspect of the charter is to see what = extensions  in our protocols may be necessary to be able to carry out one or = another policy.  But for the spec that we are doing to describe the = relationships between multiple streams so that they can be reasonably rendered, I = think we need to have that description work for any of the composition models = (meaning sender composed or receiver composed).

 

What do you think?

 

Allyn=

 ----------
From: Peter Musgrave <peter.musgrave@magorcorp.com= >
Date: Thu, Dec 2, 2010 at 2:02 PM
To: "Mike Hammer (hmmr)" <hmmr@cisco.com>
Cc: maitai@ietf.org


I think this is actually a different, very interesting issue. This = speaks to control DURING the call and the need for that to be dynamic. I = completely agree - but as understand the charter it's out of scope...although I think it = is inevitable that we will need to look at what exists (BFCP, conference = event etc.) and determine if it can be used or start to define something = new.

This might be subverted by sending all and letting the receiver take = them on and off hold quickly...clunky but avoid protocol work.

My specific question relates to the initial setup where I have two 3 = display, 3 camera systems from different vendors. Who decides which stream goes = where? Sender or receiver?

Peter


----------
 

 

------_=_NextPart_001_01CBADE6.0C2A7CA5-- From wwwrun@core3.amsl.com Tue Jan 11 10:17:28 2011 Return-Path: X-Original-To: clue@ietf.org Delivered-To: clue@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id AD2D13A6A62; Tue, 11 Jan 2011 10:17:28 -0800 (PST) From: IESG Secretary To: IETF Announcement list Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20110111181728.AD2D13A6A62@core3.amsl.com> Date: Tue, 11 Jan 2011 10:17:28 -0800 (PST) Cc: clue@ietf.org Subject: [clue] WG Action: ControLling mUltiple streams for tElepresence (clue) 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, 11 Jan 2011 18:17:28 -0000 A new IETF working group has been formed in the Real-time Applications and Infrastructure Area. For additional information, please contact the Area Directors or the WG Chairs. ControLling mUltiple streams for tElepresence (clue) ------------------------------------------- Current Status: Active Working Group Chair(s): Paul Kyzivat Mary Barnes Real-time Applications and Infrastructure Area Director(s): Gonzalo Camarillo Robert Sparks Real-time Applications and Infrastructure Area Advisor: Gonzalo Camarillo Mailing Lists: Address: clue@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/clue Archive: http://www.ietf.org/mail-archive/web/clue/ Description of Working Group: In the context of this WG, the term telepresence is used in a general manner to describe systems that provide high definition, high quality audio/video enabling a "being-there" experience. One example is an immersive telepresence system using specially designed and special purpose rooms with multiple displays permitting life size image reproduction using multiple cameras, encoders, decoders, microphones and loudspeakers. Current telepresence systems are based on open standards such as RTP, SIP, H.264, the H.323 suite. However, they cannot easily interoperate with each other without operator assistance and expensive additional equipment which translates from one vendor to another. A major factor limiting the interoperability of telepresence systems is the lack of a standardized way to describe and negotiate the use of the multiple streams of audio and video comprising the media flows. The WG will create specifications for SIP-based conferencing systems to enable communication of information about media streams so that a sending system, receiving system, or intermediate system can make reasonable decisions about transmitting, selecting, and rendering media streams. This enables systems to make choices that optimize user experience. This working group is chartered to specify the following information about media streams from one entity to another entity: * Spatial relationships of cameras, displays, microphones, and loudspeakers - relative to each other and to likely positions of participants * Viewpoint, field of view/capture for camera/microphone/display/loudspeaker - so that senders and intermediate devices can understand how best to compose streams for receivers, and the receiver will know the characteristics of its received streams * Usage of the stream, for example whether the stream is presentation, or document camera output * Aspect ratio of cameras and displays * Which sources a receiver wants to receive. For example, it might want the source for the left camera, or might want the source chosen by VAD (Voice Activity Detection) Information between sources and sinks about media stream capabilities will be exchanged. The working group will define the semantics, syntax, and transport mechanism for communicating the necessary information. It will consider whether existing protocols for signaling, messaging and transport are adequate or need to be extended. Any extensions to IETF protocols will be done in appropriate WGs, for example extensions to SDP in MMUSIC. The scope of the work includes describing relatively static relations between entities (participants and devices). It also includes handling more dynamic relationships, such as specifying the audio and video streams for defined speakers. Specifying the location of the current speakers relative to display microphones needs to be provided dynamically as speakers move. As part of the receiver telling the sender what it wants dynamically, explicit receiver notification to the sender of the desired video stream and video pause will be considered. The scope includes both systems that provide a fully immersive experience, and systems that interwork with them and therefore need to understand the same multiple stream semantics. The focus of this work is on multiple RTP audio and video streams. Other media types may be considered, however development of methodologies for them is not within the scope of this work. Interoperation with SIP and related standards for audio and video is required. However, backwards compatibility with existing non-standards compliant telepresence systems is not required. This working group is not currently chartered to work on issues of continuous conference control including: far end camera control, floor control, conference roster. The working group may identify interoperability obstacles in existing open standards. If so, the WG will develop requirements to be communicated to other IETF WGs or Standards Forums, or recharter as appropriate. Reuse of existing protocols and backwards compatibility with SIP-compliant audio/video endpoints are important factors for the working group to consider. The work will closely coordinate with the appropriate areas (e.g., OPS and SEC), and working groups including AVT, MMUSIC, MEDIACTRL, XCON, and SIPCORE. Goals and Milestones: Jul 2011 Submit informational draft to IESG on use cases Jul 2011 Submit informational draft to IESG on framework and requirements Nov 2011 Submit standards track specification(s) to IESG to support framework and requirements From gonzalo.camarillo@ericsson.com Tue Jan 11 10:49:31 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 C6B4E3A682F for ; Tue, 11 Jan 2011 10:49:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.606 X-Spam-Level: X-Spam-Status: No, score=-106.606 tagged_above=-999 required=5 tests=[AWL=-0.007, 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 EoTPZBh6oXTH for ; Tue, 11 Jan 2011 10:49:29 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id CB4E53A681B for ; Tue, 11 Jan 2011 10:49:21 -0800 (PST) X-AuditID: c1b4fb3d-b7b89ae0000036a3-e3-4d2ca6ba9c3a Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id A5.18.13987.AB6AC2D4; Tue, 11 Jan 2011 19:51:38 +0100 (CET) Received: from [131.160.126.193] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.2.234.1; Tue, 11 Jan 2011 19:51:37 +0100 Message-ID: <4D2CA6B9.7010804@ericsson.com> Date: Tue, 11 Jan 2011 20:51:37 +0200 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: "clue@ietf.org" References: <20110111181728.AD2D13A6A62@core3.amsl.com> In-Reply-To: <20110111181728.AD2D13A6A62@core3.amsl.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Subject: Re: [clue] WG Action: ControLling mUltiple streams for tElepresence (clue) 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, 11 Jan 2011 18:49:31 -0000 Hi, as you can see in the announcement below, this WG has now been officially created: https://datatracker.ietf.org/wg/clue/charter/ Cheers, Gonzalo On 11/01/2011 8:17 PM, IESG Secretary wrote: > A new IETF working group has been formed in the Real-time Applications and > Infrastructure Area. For additional information, please contact the Area > Directors or the WG Chairs. > > ControLling mUltiple streams for tElepresence (clue) > ------------------------------------------- > Current Status: Active Working Group > > Chair(s): > Paul Kyzivat > Mary Barnes > > Real-time Applications and Infrastructure Area Director(s): > Gonzalo Camarillo > Robert Sparks > > Real-time Applications and Infrastructure Area Advisor: > Gonzalo Camarillo > > Mailing Lists: > Address: clue@ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/clue > Archive: http://www.ietf.org/mail-archive/web/clue/ > > Description of Working Group: > > In the context of this WG, the term telepresence is used in a general > manner to describe systems that provide high definition, high quality > audio/video enabling a "being-there" experience. One example is an > immersive telepresence system using specially designed and special > purpose rooms with multiple displays permitting life size image > reproduction using multiple cameras, encoders, decoders, microphones > and loudspeakers. > > Current telepresence systems are based on open standards such as RTP, > SIP, H.264, the H.323 suite. However, they cannot easily interoperate > with each other without operator assistance and expensive additional > equipment which translates from one vendor to another. A major factor > limiting the interoperability of telepresence systems is the lack of a > standardized way to describe and negotiate the use of the multiple > streams of audio and video comprising the media flows. > > The WG will create specifications for SIP-based conferencing systems > to enable communication of information about media streams so that a > sending system, receiving system, or intermediate system can make > reasonable decisions about transmitting, selecting, and rendering > media streams. This enables systems to make choices that optimize user > experience. > > This working group is chartered to specify the following information > about media streams from one entity to another entity: > > * Spatial relationships of cameras, displays, microphones, and > loudspeakers - relative to each other and to likely positions of > participants > > * Viewpoint, field of view/capture for > camera/microphone/display/loudspeaker - so that senders and > intermediate devices can understand how best to compose streams for > receivers, and the receiver will know the characteristics of its > received streams > > * Usage of the stream, for example whether the stream is presentation, > or document camera output > > * Aspect ratio of cameras and displays > > * Which sources a receiver wants to receive. For example, it might > want the source for the left camera, or might want the source chosen > by VAD (Voice Activity Detection) > > Information between sources and sinks about media stream capabilities > will be exchanged. > > The working group will define the semantics, syntax, and transport > mechanism for communicating the necessary information. It will > consider whether existing protocols for signaling, messaging and > transport are adequate or need to be extended. Any extensions to IETF > protocols will be done in appropriate WGs, for example extensions to > SDP in MMUSIC. > > The scope of the work includes describing relatively static relations > between entities (participants and devices). It also includes handling > more dynamic relationships, such as specifying the audio and video > streams for defined speakers. Specifying the location of the current > speakers relative to display microphones needs to be provided > dynamically as speakers move. > > As part of the receiver telling the sender what it wants dynamically, > explicit receiver notification to the sender of the desired video > stream and video pause will be considered. > > The scope includes both systems that provide a fully immersive > experience, and systems that interwork with them and therefore need to > understand the same multiple stream semantics. > > The focus of this work is on multiple RTP audio and video streams. > Other media types may be considered, however development of > methodologies for them is not within the scope of this work. > > Interoperation with SIP and related standards for audio and video is > required. However, backwards compatibility with existing > non-standards compliant telepresence systems is not required. > > This working group is not currently chartered to work on issues of > continuous conference control including: far end camera control, floor > control, conference roster. The working group may identify > interoperability obstacles in existing open standards. If so, the WG > will develop requirements to be communicated to other IETF WGs or > Standards Forums, or recharter as appropriate. > > Reuse of existing protocols and backwards compatibility with > SIP-compliant audio/video endpoints are important factors for the > working group to consider. The work will closely coordinate with the > appropriate areas (e.g., OPS and SEC), and working groups including > AVT, MMUSIC, MEDIACTRL, XCON, and SIPCORE. > > > Goals and Milestones: > > Jul 2011 Submit informational draft to IESG on use cases > Jul 2011 Submit informational draft to IESG on framework and > requirements > Nov 2011 Submit standards track specification(s) to IESG to support > framework and requirements > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From allyn@cisco.com Tue Jan 11 15:55:19 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 8381F3A679F for ; Tue, 11 Jan 2011 15:55:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.513 X-Spam-Level: X-Spam-Status: No, score=-10.513 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 V+hiVPoDL0ao for ; Tue, 11 Jan 2011 15:55:17 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 554183A6767 for ; Tue, 11 Jan 2011 15:55:16 -0800 (PST) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Al4JAJJ9LE2rRN+K/2dsb2JhbACCOpNwhhaHe3OkJZhfhUwEhGeJSw Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-2.cisco.com with ESMTP; 11 Jan 2011 23:57:34 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id p0BNvXXc029265 for ; Tue, 11 Jan 2011 23:57:34 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); Tue, 11 Jan 2011 15:57:28 -0800 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_01CBB1EB.4CFEFB72" Date: Tue, 11 Jan 2011 15:57:26 -0800 Message-ID: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC03542672@xmb-sjc-221.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I just submitted the use case and problem statement drafts under CLUE instead of DISPATCH Thread-Index: Acux60x8D8As1vKCQCG/le27khnsXA== From: "Allyn Romanow (allyn)" To: X-OriginalArrivalTime: 11 Jan 2011 23:57:28.0083 (UTC) FILETIME=[4D334E30:01CBB1EB] Subject: [clue] I just submitted the use case and problem statement drafts under CLUE instead of DISPATCH 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, 11 Jan 2011 23:55:19 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBB1EB.4CFEFB72 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable No significant changes were made-an editorial change in each. =20 =20 Allyn ------_=_NextPart_001_01CBB1EB.4CFEFB72 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

No significant changes were made—an editorial = change in each.

 

 

Allyn

------_=_NextPart_001_01CBB1EB.4CFEFB72-- From gonzalo.camarillo@ericsson.com Fri Jan 28 04:06: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 E6D253A67E4 for ; Fri, 28 Jan 2011 04:06:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.613 X-Spam-Level: X-Spam-Status: No, score=-106.613 tagged_above=-999 required=5 tests=[AWL=-0.014, 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 Ie-bz-EqVXxv for ; Fri, 28 Jan 2011 04:06:27 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id F3D2A3A67FB for ; Fri, 28 Jan 2011 04:06:23 -0800 (PST) X-AuditID: c1b4fb39-b7cfbae000005c8e-98-4d42b1f80a1d Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 30.BD.23694.8F1B24D4; Fri, 28 Jan 2011 13:09:28 +0100 (CET) Received: from [131.160.126.194] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.2.234.1; Fri, 28 Jan 2011 13:09:28 +0100 Message-ID: <4D42B1F8.8040703@ericsson.com> Date: Fri, 28 Jan 2011 14:09:28 +0200 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: clue@ietf.org X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Subject: [clue] Resume discussions 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: Fri, 28 Jan 2011 12:06:28 -0000 Hi, I have seen little activity since this WG was chartered. It would be great if we could resume list discussions at this point. Thanks, Gonzalo From allyn@cisco.com Fri Jan 28 06:39:30 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 4D3063A6879 for ; Fri, 28 Jan 2011 06:39:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.519 X-Spam-Level: X-Spam-Status: No, score=-10.519 tagged_above=-999 required=5 tests=[AWL=0.080, 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 tlXDHDjynu6E for ; Fri, 28 Jan 2011 06:39:29 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 96EA73A67B3 for ; Fri, 28 Jan 2011 06:39:29 -0800 (PST) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnYEAIdkQk2rR7Ht/2dsb2JhbACWIo5ec6Azm1iFTwSFGIpZ Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-2.cisco.com with ESMTP; 28 Jan 2011 14:42:36 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p0SEga7G021380; Fri, 28 Jan 2011 14:42:36 GMT Received: from xmb-sjc-221.amer.cisco.com ([128.107.191.80]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 28 Jan 2011 06:42:36 -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: Fri, 28 Jan 2011 06:42:34 -0800 Message-ID: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC03726425@xmb-sjc-221.amer.cisco.com> In-Reply-To: <4D42B1F8.8040703@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] Resume discussions Thread-Index: Acu+5D6+oeCe/vSBRyKMsZ5b00joBQAE8wrQ References: <4D42B1F8.8040703@ericsson.com> From: "Allyn Romanow (allyn)" To: "Gonzalo Camarillo" , X-OriginalArrivalTime: 28 Jan 2011 14:42:36.0209 (UTC) FILETIME=[9AB83A10:01CBBEF9] Subject: Re: [clue] Resume discussions 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: Fri, 28 Jan 2011 14:39:30 -0000 Hi Gonzalo and all, I think it would be good if we could hone the use case draft and I'm middle of updating it to include a case for participants on heterogeneous devices in addition to immersive. I'll submitting that in the next few days. It would be great to get people's feedback on the draft - both what user based use cases are missing, and how the ones already there might be improved. =20 thanks Allyn > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On=20 > Behalf Of Gonzalo Camarillo > Sent: Friday, January 28, 2011 4:09 AM > To: clue@ietf.org > Subject: [clue] Resume discussions >=20 > Hi, >=20 > I have seen little activity since this WG was chartered. It=20 > would be great if we could resume list discussions at this point. >=20 > Thanks, >=20 > Gonzalo > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue >=20 From peter.musgrave@magorcorp.com Fri Jan 28 23:48:48 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 C84A03A6A71 for ; Fri, 28 Jan 2011 23:48:48 -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.001, 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 GeeQwI2hYc4W for ; Fri, 28 Jan 2011 23:48:47 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 7E9F23A6A64 for ; Fri, 28 Jan 2011 23:48:47 -0800 (PST) Received: by wyf23 with SMTP id 23so4104921wyf.31 for ; Fri, 28 Jan 2011 23:51:55 -0800 (PST) Received: by 10.227.20.84 with SMTP id e20mr3746464wbb.70.1296287515235; Fri, 28 Jan 2011 23:51:55 -0800 (PST) Received: from [192.168.1.149] (host86-177-223-89.range86-177.btcentralplus.com [86.177.223.89]) by mx.google.com with ESMTPS id y29sm8193874wbd.16.2011.01.28.23.51.53 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 28 Jan 2011 23:51:54 -0800 (PST) From: Peter Musgrave Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sat, 29 Jan 2011 02:51:52 -0500 Message-Id: <9EEB6465-626A-43B9-A653-A9B67FC01E80@magorcorp.com> To: CLUE Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Subject: [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: Sat, 29 Jan 2011 07:48:48 -0000 All,=20 CLUE needs to send multiple audio and video streams between endpoints. = TIP (see imtc.org) is an existing (somewhat limited) TP interop protocol = which made a decision to mux the multiple video data streams into a = single RTP flow (i.e. send all to the same destination port) = distinguishing them by SSRC id. Audio is treated similarly. This has some significant advantages: - middle boxes still see one video m-line and do not need to change - ICE needs to run only once for the media stream - encryption can cover all the payload with one key pair The disadvantage is that there now needs to be a mapping of data to = logical RTP "channels" and this needs to be conveyed somehow. If this is = done in SDP then I would think mmusic work would be required to specify = it. I think the notion of a single, multiplexed video stream for a TP = endpoint makes a lot of sense in the context of CLUE. Are there reasons not to mux? Regards,=20 Peter Musgrave= From lorenzo@meetecho.com Sat Jan 29 00:38: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 0718B3A6AF2 for ; Sat, 29 Jan 2011 00:38:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] 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 SBLlujQHSV0Y for ; Sat, 29 Jan 2011 00:38:38 -0800 (PST) Received: from smtplq04.aruba.it (smtplq-out17.aruba.it [62.149.158.37]) by core3.amsl.com (Postfix) with SMTP id 8DA5A3A6AE9 for ; Sat, 29 Jan 2011 00:38:37 -0800 (PST) Received: (qmail 19539 invoked by uid 89); 29 Jan 2011 08:41:41 -0000 Received: from unknown (HELO smtp1.aruba.it) (62.149.158.221) by smtplq04.aruba.it with SMTP; 29 Jan 2011 08:41:41 -0000 Received: (qmail 23644 invoked by uid 89); 29 Jan 2011 08:41:40 -0000 Received: from unknown (HELO rainpc) (lorenzo@meetecho.com@79.51.38.82) by smtp1.ad.aruba.it with SMTP; 29 Jan 2011 08:41:40 -0000 Date: Sat, 29 Jan 2011 09:35:16 +0100 From: Lorenzo Miniero To: Peter Musgrave Message-Id: <20110129093516.673baddb.lorenzo@meetecho.com> In-Reply-To: <9EEB6465-626A-43B9-A653-A9B67FC01E80@magorcorp.com> References: <9EEB6465-626A-43B9-A653-A9B67FC01E80@magorcorp.com> Organization: Meetecho X-Mailer: Sylpheed 3.1.0beta5 (GTK+ 2.22.0; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Rating: smtp1.ad.aruba.it 1.6.2 0/1000/N X-Spam-Rating: smtplq04.aruba.it 1.6.2 0/1000/N 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: Sat, 29 Jan 2011 08:38:39 -0000 Well, if I have to think about a reason not to, muxing/demuxing at an application level is surely less efficient than doing it at a transport level. Besides, the RTP channel could get "overloaded", which could be an issue with packet shapers/discarders (if any). But I guess that, if those you mentioned are the advantages, that's not a real dealbreaker. L. On Sat, 29 Jan 2011 02:51:52 -0500 Peter Musgrave wrote: > All, > > CLUE needs to send multiple audio and video streams between endpoints. TIP (see imtc.org) is an existing (somewhat limited) TP interop protocol which made a decision to mux the multiple video data streams into a single RTP flow (i.e. send all to the same destination port) distinguishing them by SSRC id. Audio is treated similarly. > > This has some significant advantages: > - middle boxes still see one video m-line and do not need to change > - ICE needs to run only once for the media stream > - encryption can cover all the payload with one key pair > > The disadvantage is that there now needs to be a mapping of data to logical RTP "channels" and this needs to be conveyed somehow. If this is done in SDP then I would think mmusic work would be required to specify it. > > I think the notion of a single, multiplexed video stream for a TP endpoint makes a lot of sense in the context of CLUE. > > Are there reasons not to mux? > > Regards, > > Peter Musgrave > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue -- Lorenzo Miniero From aravind.sethuraman@teliris.com Sat Jan 29 07:25:45 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 62F333A67FC for ; Sat, 29 Jan 2011 07:25:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, 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 QA2MolHcB3+m for ; Sat, 29 Jan 2011 07:25:44 -0800 (PST) Received: from imta-38.everyone.net (imta-35.everyone.net [216.200.145.35]) by core3.amsl.com (Postfix) with ESMTP id 3595C3A67A5 for ; Sat, 29 Jan 2011 07:25:44 -0800 (PST) Received: from pps.filterd (omta006 [127.0.0.1]) by imta-38.everyone.net (8.14.4/8.14.4) with SMTP id p0TFR8nD015420; Sat, 29 Jan 2011 07:28:53 -0800 Received: from dm0104.mta.everyone.net (sj1-slb03-gw2.sj2.proofpoint.com [172.16.1.96]) by imta-38.everyone.net with ESMTP id u4my703wy-1; Sat, 29 Jan 2011 07:28:53 -0800 X-Eon-Dm: dm0104 Received: by resin11.mta.everyone.net (EON-PICKUP) id resin11.4d4351cc.147d; Sat, 29 Jan 2011 07:28:43 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Message-Id: <20110129072842.CEF71BD6@resin11.mta.everyone.net> Date: Sat, 29 Jan 2011 07:28:42 -0800 From: "Aravind Sethuraman" To: "Lorenzo Miniero" X-Eon-Sig: AQLO6zJNRDIrprPZsgEAAAAD,a055fb4b2373f7e7f1d8ff3fdbc21178 X-Originating-Ip: 122.164.62.218 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=2 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1012030000 definitions=main-1101290043 Cc: clue@ietf.org Subject: Re: [clue] Multiple Streams - RTP muxing? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: aravind.sethuraman@teliris.com List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jan 2011 15:25:45 -0000 Hi, Is not transport level RTP muxing and demuxing expensive on low end applications? Can we not support both RTP muxing and multiple m lines as part of the session establishment? Regards, Aravind --- lorenzo@meetecho.com wrote: From: Lorenzo Miniero To: Peter Musgrave Cc: CLUE Subject: Re: [clue] Multiple Streams - RTP muxing? Date: Sat, 29 Jan 2011 09:35:16 +0100 Well, if I have to think about a reason not to, muxing/demuxing at an application level is surely less efficient than doing it at a transport level. Besides, the RTP channel could get "overloaded", which could be an issue with packet shapers/discarders (if any). But I guess that, if those you mentioned are the advantages, that's not a real dealbreaker. L. On Sat, 29 Jan 2011 02:51:52 -0500 Peter Musgrave wrote: > All, > > CLUE needs to send multiple audio and video streams between endpoints. TIP (see imtc.org) is an existing (somewhat limited) TP interop protocol which made a decision to mux the multiple video data streams into a single RTP flow (i.e. send all to the same destination port) distinguishing them by SSRC id. Audio is treated similarly. > > This has some significant advantages: > - middle boxes still see one video m-line and do not need to change > - ICE needs to run only once for the media stream > - encryption can cover all the payload with one key pair > > The disadvantage is that there now needs to be a mapping of data to logical RTP "channels" and this needs to be conveyed somehow. If this is done in SDP then I would think mmusic work would be required to specify it. > > I think the notion of a single, multiplexed video stream for a TP endpoint makes a lot of sense in the context of CLUE. > > Are there reasons not to mux? > > Regards, > > Peter Musgrave > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue -- Lorenzo Miniero _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue From stephen.botzko@gmail.com Sat Jan 29 07:56:11 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 4EC233A6814 for ; Sat, 29 Jan 2011 07:56:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.262 X-Spam-Level: X-Spam-Status: No, score=-3.262 tagged_above=-999 required=5 tests=[AWL=0.336, 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 pyrw+1uMi+WA for ; Sat, 29 Jan 2011 07:56:09 -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 6138D3A6807 for ; Sat, 29 Jan 2011 07:56:09 -0800 (PST) Received: by qwi2 with SMTP id 2so4463785qwi.31 for ; Sat, 29 Jan 2011 07:59: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=SFZtjoel1b/Jc0kIWWHsqZ3JsygmIW1cB31Dr8DXvaw=; b=vH1wlQXIOxQIpXC/EDXyJESHBNorSN71Tm+IEHHGlqMTL3XmW+MWloR1+Q3tEfxkLl DvLIbmv4GLlCX945NQkA0gxetXoH8UdPUh3yAZBHffsIlGd/udocZFm/c7tC9mCuXjvz /hVc62kM9cRwrWw4//25pjLPV48vnPJTkiiI0= 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=xtTWBRLCsCIpzfMmxWCWqkDgs3G6VR/CjKwRjk1pUrFAHyIwHWTKqTIA9xYFjlwnP+ J0oRujCB+TbfUG1M4NsOhbA0XJ8cGPIaD5BaxZBYomR6y11a2U86wmAVhsBQnw89wwxu zLvo+lIehG+A4po2Rd3hQnXSRQFfdkRdJDRa4= MIME-Version: 1.0 Received: by 10.224.20.4 with SMTP id d4mr4132960qab.345.1296316757770; Sat, 29 Jan 2011 07:59:17 -0800 (PST) Received: by 10.220.128.30 with HTTP; Sat, 29 Jan 2011 07:59:17 -0800 (PST) In-Reply-To: <20110129072842.CEF71BD6@resin11.mta.everyone.net> References: <20110129072842.CEF71BD6@resin11.mta.everyone.net> Date: Sat, 29 Jan 2011 10:59:17 -0500 Message-ID: From: Stephen Botzko To: aravind.sethuraman@teliris.com Content-Type: multipart/alternative; boundary=0015175cda2cdd0431049afe4308 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: Sat, 29 Jan 2011 15:56:11 -0000 --0015175cda2cdd0431049afe4308 Content-Type: text/plain; charset=ISO-8859-1 >>> Is not transport level RTP muxing and demuxing expensive on low end applications? >>> If the video/audio decoding is done in the same unit as the RTP sender/receiver, then I don't see any more computation being needed. If some or all the audio/video decoding is done in satellite units, then there are some extra cycles that are needed to forward the RTP packets in both directions. This is very small compared to the real complexity, which is in the audio/video codecs. Transport level multiplexing has some other advantages, which I think are more important than the cycles. NAT traversal is simpler, and session border controllers require less call state. And it is easier to manage bandwidth. In some existing videoconferencing use cases, accurate RSVP flow specs are impossible to craft, since the individual media flows are dynamic (though the total is not). With transport multiplexing, this problem goes away. >>> Can we not support both RTP muxing and multiple m lines as part of the session establishment? >>> We can, but we are talking about a *lot* of m lines, given the number of streams and the number of different codec options these systems already use. This is an option certainly, though it may be simpler for everyone if we could agree to multiplex (or not). Stephen Botzko On Sat, Jan 29, 2011 at 10:28 AM, Aravind Sethuraman < aravind.sethuraman@teliris.com> wrote: > Hi, > > Is not transport level RTP muxing and demuxing expensive on low end > applications? > Can we not support both RTP muxing and multiple m lines as part of the > session establishment? > > Regards, > Aravind > > > --- lorenzo@meetecho.com wrote: > > From: Lorenzo Miniero > To: Peter Musgrave > Cc: CLUE > Subject: Re: [clue] Multiple Streams - RTP muxing? > Date: Sat, 29 Jan 2011 09:35:16 +0100 > > Well, if I have to think about a reason not to, muxing/demuxing at an > application level is surely less efficient than doing it at a transport > level. Besides, the RTP channel could get "overloaded", which could be an > issue with packet shapers/discarders (if any). > > But I guess that, if those you mentioned are the advantages, that's not a > real dealbreaker. > > L. > > > On Sat, 29 Jan 2011 02:51:52 -0500 > Peter Musgrave wrote: > > > All, > > > > CLUE needs to send multiple audio and video streams between endpoints. > TIP (see imtc.org) is an existing (somewhat limited) TP interop protocol > which made a decision to mux the multiple video data streams into a single > RTP flow (i.e. send all to the same destination port) distinguishing them by > SSRC id. Audio is treated similarly. > > > > This has some significant advantages: > > - middle boxes still see one video m-line and do not need to change > > - ICE needs to run only once for the media stream > > - encryption can cover all the payload with one key pair > > > > The disadvantage is that there now needs to be a mapping of data to > logical RTP "channels" and this needs to be conveyed somehow. If this is > done in SDP then I would think mmusic work would be required to specify it. > > > > I think the notion of a single, multiplexed video stream for a TP > endpoint makes a lot of sense in the context of CLUE. > > > > Are there reasons not to mux? > > > > Regards, > > > > Peter Musgrave > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue > > > -- > Lorenzo Miniero > _______________________________________________ > 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 > --0015175cda2cdd0431049afe4308 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable >>>
=A0=A0=A0 Is not transport level RTP muxing and demuxing expensive on low end applica= tions?
>>>
If the video/audio decoding is done in the same u= nit as the RTP sender/receiver, then I don't see any more computation b= eing needed.

If some or all the audio/video decoding is done in satellite units, the= n there are some extra cycles that are needed to forward the RTP packets in= both directions.=A0 This is very small compared to the real complexity, wh= ich is in the audio/video codecs.

Transport level multiplexing has some other advantages, which I think a= re more important than the cycles. NAT traversal is simpler, and session bo= rder controllers require less call state.=A0 And it is easier to manage ban= dwidth.=A0 In some existing videoconferencing use cases, accurate RSVP flow= specs are impossible to craft, since the individual media flows are dynami= c (though the total is not).=A0 With transport multiplexing, this problem g= oes away.

>>>
=A0=A0 Can we not support both RTP muxing and multiple = m lines as part of the session establishment?
>>>

We can= , but we are talking about a lot of m lines, given the number of str= eams and the number of different codec options these systems already use. T= his is an option certainly, though it may be simpler for everyone if we cou= ld agree to multiplex (or not).

Stephen Botzko

On Sat, Jan 29, 2011 a= t 10:28 AM, Aravind Sethuraman <aravind.sethuraman@teliris.com> w= rote:
Hi,

Is not transport level RTP muxing and demuxing expensive on low end applica= tions?
Can we not support both RTP muxing and multiple m lines as part of the sess= ion establishment?

Regards,
Aravind


--- lorenzo@meetecho.com wrote:=

From: Lorenzo Miniero <lorenzo@m= eetecho.com>
To: Peter Musgrave <pete= r.musgrave@magorcorp.com>
Cc: CLUE <clue@ietf.org>
Subject: Re: [clue] Multiple Streams - RTP muxing?
Date: Sat, 29 Jan 2011 09:35:16 +0100

Well, if I have to think about a reason not to, muxing/demuxing at an appli= cation level is surely less efficient than doing it at a transport level. B= esides, the RTP channel could get "overloaded", which could be an= issue with packet shapers/discarders (if any).

But I guess that, if those you mentioned are the advantages, that's not= a real dealbreaker.

L.


On Sat, 29 Jan 2011 02:51:52 -0500
Peter Musgrave <peter.mu= sgrave@magorcorp.com> wrote:

> All,
>
> CLUE needs to send multiple audio and video streams between endpoints.= TIP (see imtc.org) is an= existing (somewhat limited) TP interop protocol which made a decision to m= ux the multiple video data streams into a single RTP flow (i.e. send all to= the same destination port) distinguishing them by SSRC id. Audio is treate= d similarly.
>
> This has some significant advantages:
> - middle boxes still see one video m-line and do not need to change > - ICE needs to run only once for the media stream
> - encryption can cover all the payload with one key pair
>
> The disadvantage is that there now needs to be a mapping of data to lo= gical RTP "channels" and this needs to be conveyed somehow. If th= is is done in SDP then I would think mmusic work would be required to speci= fy it.
>
> I think the notion of a single, multiplexed video stream for a TP endp= oint makes a lot of sense in the context of CLUE.
>
> Are there reasons not to mux?
>
> Regards,
>
> Peter Musgrave
> _______________________________________________
> clue mailing list
> clue@ietf.org
> https://www.ietf.org/mailman/listinfo/clue


--
Lorenzo Miniero <lorenzo@meetech= o.com>
_______________________________________________
clue mailing list
clue@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/clue


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

--0015175cda2cdd0431049afe4308-- From tme@americafree.tv Sat Jan 29 08:31:11 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 54E123A6834 for ; Sat, 29 Jan 2011 08:31:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.294 X-Spam-Level: X-Spam-Status: No, score=-102.294 tagged_above=-999 required=5 tests=[AWL=0.305, 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 oYaICTwBXXY6 for ; Sat, 29 Jan 2011 08:31:10 -0800 (PST) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id E79973A6833 for ; Sat, 29 Jan 2011 08:31:09 -0800 (PST) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id BC7F19C65AB9; Sat, 29 Jan 2011 11:34:18 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Marshall Eubanks In-Reply-To: <20110129072842.CEF71BD6@resin11.mta.everyone.net> Date: Sat, 29 Jan 2011 11:34:17 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <732B2453-EC2F-405F-8368-A4826FE6CC37@americafree.tv> References: <20110129072842.CEF71BD6@resin11.mta.everyone.net> To: aravind.sethuraman@teliris.com X-Mailer: Apple Mail (2.1081) 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: Sat, 29 Jan 2011 16:31:11 -0000 On Jan 29, 2011, at 10:28 AM, Aravind Sethuraman wrote: > Hi, >=20 > Is not transport level RTP muxing and demuxing expensive on low end = applications? Yes. That is my worry here. Extracting one screen from a muxed set up = screens would be harder for middleware.=20 There also may be technical issues about timing. If a video bridge is = going to combine and mux two streams from two different sources, say to send to a multi-screen TP unit, then won't the two = clocks have to be reconciled ?=20 > Can we not support both RTP muxing and multiple m lines as part of the = session establishment? >=20 Are you saying support both as either-or options ? Regards Marshall=20 > Regards, > Aravind >=20 >=20 > --- lorenzo@meetecho.com wrote: >=20 > From: Lorenzo Miniero > To: Peter Musgrave > Cc: CLUE > Subject: Re: [clue] Multiple Streams - RTP muxing? > Date: Sat, 29 Jan 2011 09:35:16 +0100 >=20 > Well, if I have to think about a reason not to, muxing/demuxing at an = application level is surely less efficient than doing it at a transport = level. Besides, the RTP channel could get "overloaded", which could be = an issue with packet shapers/discarders (if any). >=20 > But I guess that, if those you mentioned are the advantages, that's = not a real dealbreaker. >=20 > L. >=20 >=20 > On Sat, 29 Jan 2011 02:51:52 -0500 > Peter Musgrave wrote: >=20 >> All,=20 >>=20 >> CLUE needs to send multiple audio and video streams between = endpoints. TIP (see imtc.org) is an existing (somewhat limited) TP = interop protocol which made a decision to mux the multiple video data = streams into a single RTP flow (i.e. send all to the same destination = port) distinguishing them by SSRC id. Audio is treated similarly. >>=20 >> This has some significant advantages: >> - middle boxes still see one video m-line and do not need to change >> - ICE needs to run only once for the media stream >> - encryption can cover all the payload with one key pair >>=20 >> The disadvantage is that there now needs to be a mapping of data to = logical RTP "channels" and this needs to be conveyed somehow. If this is = done in SDP then I would think mmusic work would be required to specify = it. >>=20 >> I think the notion of a single, multiplexed video stream for a TP = endpoint makes a lot of sense in the context of CLUE. >>=20 >> Are there reasons not to mux? >>=20 >> Regards,=20 >>=20 >> Peter Musgrave >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >=20 >=20 > --=20 > Lorenzo Miniero > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue >=20 >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue >=20 From SRS0=2S8jPP=U3=att.blackberry.net=aravindsethuraman@srs.bis.na.blackberry.com Sat Jan 29 08:55:51 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 6C6503A684E for ; Sat, 29 Jan 2011 08:55:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.846 X-Spam-Level: X-Spam-Status: No, score=-4.846 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, 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 S+EJVHTWyRRw for ; Sat, 29 Jan 2011 08:55:50 -0800 (PST) Received: from smtp15.bis.na.blackberry.com (smtp15.bis.na.blackberry.com [216.9.248.29]) by core3.amsl.com (Postfix) with ESMTP id 0E7BC3A6838 for ; Sat, 29 Jan 2011 08:55:49 -0800 (PST) Received: from bda2913.bisx.prod.on.blackberry (bda2913.bisx.prod.on.blackberry [172.20.204.174]) by srs.bis.na.blackberry.com (8.13.7 TEAMON/8.13.7) with ESMTP id p0TGr5jZ004211; Sat, 29 Jan 2011 16:58:57 GMT X-rim-org-msg-ref-id: 1183102328 Message-ID: <1183102328-1296320337-cardhu_decombobulator_blackberry.rim.net-1610725462-@bda2913.bisx.prod.on.blackberry> Content-Transfer-Encoding: base64 X-Priority: Normal References: <20110129072842.CEF71BD6@resin11.mta.everyone.net><732B2453-EC2F-405F-8368-A4826FE6CC37@americafree.tv> In-Reply-To: <732B2453-EC2F-405F-8368-A4826FE6CC37@americafree.tv> Sensitivity: Normal Importance: Normal To: "Marshall Eubanks" , "Aravind Sethuraman" From: aravind.sethuraman@teliris.com Date: Sat, 29 Jan 2011 17:04:25 +0000 Content-Type: text/plain MIME-Version: 1.0 Cc: clue@ietf.org Subject: Re: [clue] Multiple Streams - RTP muxing? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: aravind.sethuraman@teliris.com List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jan 2011 17:06:03 -0000 RWl0aGVyIG9yIG9wdGlvbnMuDQpUaGUgZW5kIHBvaW50IGNhbiBkZWNpZGUgd2hhdCBpcyB0aGUg b3B0aW1hbCB3YXkgb2YgcmVjZWl2aW5nIGluZm9ybWF0aW9uIGFib3V0IG11bHRpcGxlIHN0cmVh bXMuDQoNCkFsc28gQHN0ZXBoZW4sIGhvdyBtdWNoIGlzIHRvbyBtYW55IG0gbGluZXM/IEFyZSB0 aGV5IG5vdCByZXN0cmljdGVkIGJ5IGFuIGVuZCBwb2ludHMgcGh5c2ljYWwgIyBvZiBjYXB0dXJl cyBhbmQvb3IgZGlzcGxheSB1bml0cz8NCk9yIGFyZSB3ZSBjb25zaWRlcmluZyBydHAgcmVsYXkg ZnVuY3Rpb25hbGl0aWVzIHRvbz8NCg0KDQpTZW50IHZpYSBCbGFja0JlcnJ5IGJ5IEFUJlQNCg0K LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IE1hcnNoYWxsIEV1YmFua3MgPHRtZUBh bWVyaWNhZnJlZS50dj4NCkRhdGU6IFNhdCwgMjkgSmFuIDIwMTEgMTE6MzQ6MTcgDQpUbzogPGFy YXZpbmQuc2V0aHVyYW1hbkB0ZWxpcmlzLmNvbT4NCkNjOiBMb3JlbnpvIE1pbmllcm88bG9yZW56 b0BtZWV0ZWNoby5jb20+OyA8Y2x1ZUBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbY2x1ZV0gTXVs dGlwbGUgU3RyZWFtcyAtIFJUUCBtdXhpbmc/DQoNCg0KT24gSmFuIDI5LCAyMDExLCBhdCAxMDoy OCBBTSwgQXJhdmluZCBTZXRodXJhbWFuIHdyb3RlOg0KDQo+IEhpLA0KPiANCj4gSXMgbm90IHRy YW5zcG9ydCBsZXZlbCBSVFAgbXV4aW5nIGFuZCBkZW11eGluZyBleHBlbnNpdmUgb24gbG93IGVu ZCBhcHBsaWNhdGlvbnM/DQoNClllcy4gVGhhdCBpcyBteSB3b3JyeSBoZXJlLiBFeHRyYWN0aW5n IG9uZSBzY3JlZW4gZnJvbSBhIG11eGVkIHNldCB1cCBzY3JlZW5zIHdvdWxkIGJlIGhhcmRlciBm b3IgbWlkZGxld2FyZS4gDQoNClRoZXJlIGFsc28gbWF5IGJlICB0ZWNobmljYWwgaXNzdWVzIGFi b3V0IHRpbWluZy4gSWYgYSB2aWRlbyBicmlkZ2UgaXMgZ29pbmcgdG8gY29tYmluZSBhbmQgbXV4 IHR3byBzdHJlYW1zIGZyb20gdHdvIGRpZmZlcmVudA0Kc291cmNlcywgc2F5IHRvIHNlbmQgdG8g YSBtdWx0aS1zY3JlZW4gVFAgdW5pdCwgdGhlbiB3b24ndCB0aGUgdHdvIGNsb2NrcyBoYXZlIHRv IGJlIHJlY29uY2lsZWQgPyANCg0KPiBDYW4gd2Ugbm90IHN1cHBvcnQgYm90aCBSVFAgbXV4aW5n IGFuZCBtdWx0aXBsZSBtIGxpbmVzIGFzIHBhcnQgb2YgdGhlIHNlc3Npb24gZXN0YWJsaXNobWVu dD8NCj4gDQoNCkFyZSB5b3Ugc2F5aW5nIHN1cHBvcnQgYm90aCBhcyBlaXRoZXItb3Igb3B0aW9u cyA/DQoNClJlZ2FyZHMNCk1hcnNoYWxsIA0KDQo+IFJlZ2FyZHMsDQo+IEFyYXZpbmQNCj4gDQo+ IA0KPiAtLS0gbG9yZW56b0BtZWV0ZWNoby5jb20gd3JvdGU6DQo+IA0KPiBGcm9tOiBMb3Jlbnpv IE1pbmllcm8gPGxvcmVuem9AbWVldGVjaG8uY29tPg0KPiBUbzogUGV0ZXIgTXVzZ3JhdmUgPHBl dGVyLm11c2dyYXZlQG1hZ29yY29ycC5jb20+DQo+IENjOiBDTFVFIDxjbHVlQGlldGYub3JnPg0K PiBTdWJqZWN0OiBSZTogW2NsdWVdIE11bHRpcGxlIFN0cmVhbXMgLSBSVFAgbXV4aW5nPw0KPiBE YXRlOiBTYXQsIDI5IEphbiAyMDExIDA5OjM1OjE2ICswMTAwDQo+IA0KPiBXZWxsLCBpZiBJIGhh dmUgdG8gdGhpbmsgYWJvdXQgYSByZWFzb24gbm90IHRvLCBtdXhpbmcvZGVtdXhpbmcgYXQgYW4g YXBwbGljYXRpb24gbGV2ZWwgaXMgc3VyZWx5IGxlc3MgZWZmaWNpZW50IHRoYW4gZG9pbmcgaXQg YXQgYSB0cmFuc3BvcnQgbGV2ZWwuIEJlc2lkZXMsIHRoZSBSVFAgY2hhbm5lbCBjb3VsZCBnZXQg Im92ZXJsb2FkZWQiLCB3aGljaCBjb3VsZCBiZSBhbiBpc3N1ZSB3aXRoIHBhY2tldCBzaGFwZXJz L2Rpc2NhcmRlcnMgKGlmIGFueSkuDQo+IA0KPiBCdXQgSSBndWVzcyB0aGF0LCBpZiB0aG9zZSB5 b3UgbWVudGlvbmVkIGFyZSB0aGUgYWR2YW50YWdlcywgdGhhdCdzIG5vdCBhIHJlYWwgZGVhbGJy ZWFrZXIuDQo+IA0KPiBMLg0KPiANCj4gDQo+IE9uIFNhdCwgMjkgSmFuIDIwMTEgMDI6NTE6NTIg LTA1MDANCj4gUGV0ZXIgTXVzZ3JhdmUgPHBldGVyLm11c2dyYXZlQG1hZ29yY29ycC5jb20+IHdy b3RlOg0KPiANCj4+IEFsbCwgDQo+PiANCj4+IENMVUUgbmVlZHMgdG8gc2VuZCBtdWx0aXBsZSBh dWRpbyBhbmQgdmlkZW8gc3RyZWFtcyBiZXR3ZWVuIGVuZHBvaW50cy4gVElQIChzZWUgaW10Yy5v cmcpIGlzIGFuIGV4aXN0aW5nIChzb21ld2hhdCBsaW1pdGVkKSBUUCBpbnRlcm9wIHByb3RvY29s IHdoaWNoIG1hZGUgYSBkZWNpc2lvbiB0byBtdXggdGhlIG11bHRpcGxlIHZpZGVvIGRhdGEgc3Ry ZWFtcyBpbnRvIGEgc2luZ2xlIFJUUCBmbG93IChpLmUuIHNlbmQgYWxsIHRvIHRoZSBzYW1lIGRl c3RpbmF0aW9uIHBvcnQpIGRpc3Rpbmd1aXNoaW5nIHRoZW0gYnkgU1NSQyBpZC4gQXVkaW8gaXMg dHJlYXRlZCBzaW1pbGFybHkuDQo+PiANCj4+IFRoaXMgaGFzIHNvbWUgc2lnbmlmaWNhbnQgYWR2 YW50YWdlczoNCj4+IC0gbWlkZGxlIGJveGVzIHN0aWxsIHNlZSBvbmUgdmlkZW8gbS1saW5lIGFu ZCBkbyBub3QgbmVlZCB0byBjaGFuZ2UNCj4+IC0gSUNFIG5lZWRzIHRvIHJ1biBvbmx5IG9uY2Ug Zm9yIHRoZSBtZWRpYSBzdHJlYW0NCj4+IC0gZW5jcnlwdGlvbiBjYW4gY292ZXIgYWxsIHRoZSBw YXlsb2FkIHdpdGggb25lIGtleSBwYWlyDQo+PiANCj4+IFRoZSBkaXNhZHZhbnRhZ2UgaXMgdGhh dCB0aGVyZSBub3cgbmVlZHMgdG8gYmUgYSBtYXBwaW5nIG9mIGRhdGEgdG8gbG9naWNhbCBSVFAg ImNoYW5uZWxzIiBhbmQgdGhpcyBuZWVkcyB0byBiZSBjb252ZXllZCBzb21laG93LiBJZiB0aGlz IGlzIGRvbmUgaW4gU0RQIHRoZW4gSSB3b3VsZCB0aGluayBtbXVzaWMgd29yayB3b3VsZCBiZSBy ZXF1aXJlZCB0byBzcGVjaWZ5IGl0Lg0KPj4gDQo+PiBJIHRoaW5rIHRoZSBub3Rpb24gb2YgYSBz aW5nbGUsIG11bHRpcGxleGVkIHZpZGVvIHN0cmVhbSBmb3IgYSBUUCBlbmRwb2ludCBtYWtlcyBh IGxvdCBvZiBzZW5zZSBpbiB0aGUgY29udGV4dCBvZiBDTFVFLg0KPj4gDQo+PiBBcmUgdGhlcmUg cmVhc29ucyBub3QgdG8gbXV4Pw0KPj4gDQo+PiBSZWdhcmRzLCANCj4+IA0KPj4gUGV0ZXIgTXVz Z3JhdmUNCj4+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4+IGNsdWUgbWFpbGluZyBsaXN0DQo+PiBjbHVlQGlldGYub3JnDQo+PiBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NsdWUNCj4gDQo+IA0KPiAtLSANCj4gTG9yZW56byBN aW5pZXJvIDxsb3JlbnpvQG1lZXRlY2hvLmNvbT4NCj5fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPiBjbHVlIG1haWxpbmcgbGlzdA0KPiBjbHVlQGlldGYu b3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2x1ZQ0KPiANCj4g DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gY2x1 ZSBtYWlsaW5nIGxpc3QNCj4gY2x1ZUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2NsdWUNCj4gDQoNCg== From peter.musgrave@magorcorp.com Sat Jan 29 14:29:34 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 90EE03A689C for ; Sat, 29 Jan 2011 14:29:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.726 X-Spam-Level: X-Spam-Status: No, score=-102.726 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 Y2lcMtq9iHda for ; Sat, 29 Jan 2011 14:29:32 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id 0C1B63A6894 for ; Sat, 29 Jan 2011 14:29:31 -0800 (PST) Received: by gxk27 with SMTP id 27so1768402gxk.31 for ; Sat, 29 Jan 2011 14:32:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.91.35.28 with SMTP id n28mr3227574agj.94.1296340361328; Sat, 29 Jan 2011 14:32:41 -0800 (PST) Received: by 10.90.36.7 with HTTP; Sat, 29 Jan 2011 14:32:41 -0800 (PST) In-Reply-To: <20110129072842.CEF71BD6@resin11.mta.everyone.net> References: <20110129072842.CEF71BD6@resin11.mta.everyone.net> Date: Sat, 29 Jan 2011 23:32:41 +0100 Message-ID: From: Peter Musgrave To: aravind.sethuraman@teliris.com Content-Type: multipart/alternative; boundary=001485f911c6beba29049b03c24d 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: Sat, 29 Jan 2011 22:29:35 -0000 --001485f911c6beba29049b03c24d Content-Type: text/plain; charset=ISO-8859-1 Please, no, not BOTH. I would rather HAVE to do the one I like less than to do both. Too many issues get left as "do both" - and what results in interop chaos since even if both MUST be done a vendor choses to emphasize one of the approaches in their product and the other becomes a poor non-interoperable cousin. Peter On Sat, Jan 29, 2011 at 4:28 PM, Aravind Sethuraman < aravind.sethuraman@teliris.com> wrote: > Hi, > > Is not transport level RTP muxing and demuxing expensive on low end > applications? > Can we not support both RTP muxing and multiple m lines as part of the > session establishment? > > Regards, > Aravind > > > --- lorenzo@meetecho.com wrote: > > From: Lorenzo Miniero > To: Peter Musgrave > Cc: CLUE > Subject: Re: [clue] Multiple Streams - RTP muxing? > Date: Sat, 29 Jan 2011 09:35:16 +0100 > > Well, if I have to think about a reason not to, muxing/demuxing at an > application level is surely less efficient than doing it at a transport > level. Besides, the RTP channel could get "overloaded", which could be an > issue with packet shapers/discarders (if any). > > But I guess that, if those you mentioned are the advantages, that's not a > real dealbreaker. > > L. > > > On Sat, 29 Jan 2011 02:51:52 -0500 > Peter Musgrave wrote: > > > All, > > > > CLUE needs to send multiple audio and video streams between endpoints. > TIP (see imtc.org) is an existing (somewhat limited) TP interop protocol > which made a decision to mux the multiple video data streams into a single > RTP flow (i.e. send all to the same destination port) distinguishing them by > SSRC id. Audio is treated similarly. > > > > This has some significant advantages: > > - middle boxes still see one video m-line and do not need to change > > - ICE needs to run only once for the media stream > > - encryption can cover all the payload with one key pair > > > > The disadvantage is that there now needs to be a mapping of data to > logical RTP "channels" and this needs to be conveyed somehow. If this is > done in SDP then I would think mmusic work would be required to specify it. > > > > I think the notion of a single, multiplexed video stream for a TP > endpoint makes a lot of sense in the context of CLUE. > > > > Are there reasons not to mux? > > > > Regards, > > > > Peter Musgrave > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue > > > -- > Lorenzo Miniero > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > > --001485f911c6beba29049b03c24d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Please, no, not BOTH. I would rather HAVE to do the one I like less than to= do both.=A0

Too many issues get left as "do both&q= uot; - and what results in interop chaos since even if both MUST be done a = vendor choses to=A0emphasize=A0one of the approaches in their product and t= he other becomes a poor non-interoperable cousin.=A0

Peter

On Sat, Jan 29,= 2011 at 4:28 PM, Aravind Sethuraman <aravind.sethuraman@teliris.com> wrote:
Hi,

Is not transport level RTP muxing and demuxing expensive on low end applica= tions?
Can we not support both RTP muxing and multiple m lines as part of the sess= ion establishment?

Regards,
Aravind


--- lorenzo@meetecho.com wrote:=

From: Lorenzo Miniero <lorenzo@m= eetecho.com>
To: Peter Musgrave <pete= r.musgrave@magorcorp.com>
Cc: CLUE <clue@ietf.org>
Subject: Re: [clue] Multiple Streams - RTP muxing?
Date: Sat, 29 Jan 2011 09:35:16 +0100

Well, if I have to think about a reason not to, muxing/demuxing at an appli= cation level is surely less efficient than doing it at a transport level. B= esides, the RTP channel could get "overloaded", which could be an= issue with packet shapers/discarders (if any).

But I guess that, if those you mentioned are the advantages, that's not= a real dealbreaker.

L.


On Sat, 29 Jan 2011 02:51:52 -0500
Peter Musgrave <peter.mu= sgrave@magorcorp.com> wrote:

> All,
>
> CLUE needs to send multiple audio and video streams between endpoints.= TIP (see imtc.org) is an= existing (somewhat limited) TP interop protocol which made a decision to m= ux the multiple video data streams into a single RTP flow (i.e. send all to= the same destination port) distinguishing them by SSRC id. Audio is treate= d similarly.
>
> This has some significant advantages:
> - middle boxes still see one video m-line and do not need to change > - ICE needs to run only once for the media stream
> - encryption can cover all the payload with one key pair
>
> The disadvantage is that there now needs to be a mapping of data to lo= gical RTP "channels" and this needs to be conveyed somehow. If th= is is done in SDP then I would think mmusic work would be required to speci= fy it.
>
> I think the notion of a single, multiplexed video stream for a TP endp= oint makes a lot of sense in the context of CLUE.
>
> Are there reasons not to mux?
>
> Regards,
>
> Peter Musgrave
> _______________________________________________
> clue mailing list
> clue@ietf.org
> https://www.ietf.org/mailman/listinfo/clue


--
Lorenzo Miniero <lorenzo@meetech= o.com>
_______________________________________________
clue mailing list
clue@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/clue



--001485f911c6beba29049b03c24d-- From peter.musgrave@magorcorp.com Sat Jan 29 15:14: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 C393F3A68D7 for ; Sat, 29 Jan 2011 15:14:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.598 X-Spam-Level: X-Spam-Status: No, score=-103.598 tagged_above=-999 required=5 tests=[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 b1HuTRTTCMZ1 for ; Sat, 29 Jan 2011 15:14:48 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 626313A689C for ; Sat, 29 Jan 2011 15:14:47 -0800 (PST) Received: by wwa36 with SMTP id 36so5092683wwa.13 for ; Sat, 29 Jan 2011 15:17:56 -0800 (PST) Received: by 10.227.128.208 with SMTP id l16mr4458753wbs.53.1296343075901; Sat, 29 Jan 2011 15:17:55 -0800 (PST) Received: from [10.116.1.49] (62-50-198-223.client.stsn.net [62.50.198.223]) by mx.google.com with ESMTPS id o6sm2233527wbo.21.2011.01.29.15.17.54 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 29 Jan 2011 15:17:54 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-2-208292991 From: Peter Musgrave In-Reply-To: <286AB014A111DC4C8A3720297DD5F790012BF2C6@rsmail01.avistar.com> Date: Sun, 30 Jan 2011 00:17:52 +0100 Message-Id: References: <20110129072842.CEF71BD6@resin11.mta.everyone.net> <286AB014A111DC4C8A3720297DD5F790012BF2C6@rsmail01.avistar.com> To: "Lauwers, Chris" X-Mailer: Apple Mail (2.1082) 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: Sat, 29 Jan 2011 23:14:49 -0000 --Apple-Mail-2-208292991 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi,=20 I agree with the scenarios you mention. I agree there will be a need for = multiple streams.=20 I was anticipating a discussion about *how* - even though the use cases = are still not final because I'd like to see CLUE start to tackle some of = the technical discussions which appear (to me) to be inevitable. If we = can do this in parallel with use cases then we might have a chance of = hitting our milestones.... In addition to doing the RTP muxing TIP also does the negotiation in = RTCP - which I think for many people is serious layer violation.=20 I think RTP muxing is pragmatic and I am concerned that m-lines might = get very convoluted if we do not mux. That said there still needs to be = some kind of media stream description - so perhaps that convolution is = inevitable. Peter On 2011-01-29, at 11:51 PM, Lauwers, Chris wrote: > My apologies, I=92m new to this list and I=92m trying to better = understand what the scope is of this effort. I believe what kicked off = this email thread again was Allyn=92s suggestion (hi Allyn!) to finalize = use cases. Such a document would help greatly to guide the discussion. > =20 > I can think of at least 4 scenarios of the top of my head that would = require video endpoints to send/receive multiple video streams: > =20 > - Multi-codec system (aka immersive telepresence systems). = This seems to be where most of the discussion focuses on so far. > - Systems using a relaying MCU (aka video router) for = multi-party conferences > - Endpoints exchanging both live (camera) video and = presentation video (similar to H.239) > - Systems implementing multi-party conferences using a = full-mesh paradigm > =20 > Not all of these scenarios are candidates for muxing at the transport = layer, so likely endpoints may need to be able to handle multiple RTP = streams anyway, which diminishes the appeal of RTP muxing. > =20 > Another question: if RTP muxing is deemed a good thing to do, is there = some generally-agreed on set of arguments within this group for why TIP = isn=92t an adequate protocol for this purpose? > =20 > Again, apologies if I=92m steering the conversation off-track. > =20 > =20 > Chris Lauwers > CTO, Avistar > =20 > Voice/Video: sip:lauwers@avistar.com > PSTN: +1 (650) 525.3352 > =20 > =20 > =20 > =20 > =20 > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf = Of Peter Musgrave > Sent: Saturday, January 29, 2011 2:33 PM > To: aravind.sethuraman@teliris.com > Cc: clue@ietf.org > Subject: Re: [clue] Multiple Streams - RTP muxing? > =20 > Please, no, not BOTH. I would rather HAVE to do the one I like less = than to do both.=20 > =20 > Too many issues get left as "do both" - and what results in interop = chaos since even if both MUST be done a vendor choses to emphasize one = of the approaches in their product and the other becomes a poor = non-interoperable cousin.=20 > =20 > Peter >=20 > On Sat, Jan 29, 2011 at 4:28 PM, Aravind Sethuraman = wrote: > Hi, >=20 > Is not transport level RTP muxing and demuxing expensive on low end = applications? > Can we not support both RTP muxing and multiple m lines as part of the = session establishment? >=20 > Regards, > Aravind >=20 >=20 > --- lorenzo@meetecho.com wrote: >=20 > From: Lorenzo Miniero > To: Peter Musgrave > Cc: CLUE > Subject: Re: [clue] Multiple Streams - RTP muxing? > Date: Sat, 29 Jan 2011 09:35:16 +0100 >=20 > Well, if I have to think about a reason not to, muxing/demuxing at an = application level is surely less efficient than doing it at a transport = level. Besides, the RTP channel could get "overloaded", which could be = an issue with packet shapers/discarders (if any). >=20 > But I guess that, if those you mentioned are the advantages, that's = not a real dealbreaker. >=20 > L. >=20 >=20 > On Sat, 29 Jan 2011 02:51:52 -0500 > Peter Musgrave wrote: >=20 > > All, > > > > CLUE needs to send multiple audio and video streams between = endpoints. TIP (see imtc.org) is an existing (somewhat limited) TP = interop protocol which made a decision to mux the multiple video data = streams into a single RTP flow (i.e. send all to the same destination = port) distinguishing them by SSRC id. Audio is treated similarly. > > > > This has some significant advantages: > > - middle boxes still see one video m-line and do not need to change > > - ICE needs to run only once for the media stream > > - encryption can cover all the payload with one key pair > > > > The disadvantage is that there now needs to be a mapping of data to = logical RTP "channels" and this needs to be conveyed somehow. If this is = done in SDP then I would think mmusic work would be required to specify = it. > > > > I think the notion of a single, multiplexed video stream for a TP = endpoint makes a lot of sense in the context of CLUE. > > > > Are there reasons not to mux? > > > > Regards, > > > > Peter Musgrave > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue >=20 >=20 > -- > Lorenzo Miniero > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue >=20 >=20 > =20 >=20 >=20 > This email and any files transmitted with it are confidential and = intended solely for the use of the individual or entity to whom they are = addressed.=20 > If you are not the intended recipient you are notified that = disclosing, copying, distributing or taking any action in reliance on = the contents of this information is strictly prohibited. --Apple-Mail-2-208292991 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi, 

I agree with the = scenarios you mention. I agree there will be a need for multiple = streams. 

I was anticipating a discussion = about *how* - even though the use cases are still not final because I'd = like to see CLUE start to tackle some of the technical discussions which = appear (to me) to be inevitable. If we can do this in parallel with use = cases then we might have a chance of hitting our = milestones....

In addition to doing the RTP = muxing TIP also does the negotiation in RTCP - which I think for many = people is  serious layer = violation. 

I think RTP muxing is = pragmatic and I am concerned that m-lines might get very convoluted if = we do not mux. That said there still needs to be some kind of media = stream description - so perhaps that convolution is = inevitable.

Peter

On = 2011-01-29, at 11:51 PM, Lauwers, Chris wrote:

My apologies, I=92m new to this = list and I=92m trying to  better understand what the scope is of = this effort. I believe what kicked off this email thread again was = Allyn=92s suggestion (hi Allyn!) to finalize use cases. Such a document = would help greatly to guide the discussion.
I can = think of at least 4 scenarios of the top of my head that would require = video endpoints to send/receive multiple video = streams:
- Multi-codec system (aka immersive telepresence = systems). This seems to be where most of the discussion focuses on so = far.
- Systems using a relaying MCU (aka video router) for = multi-party conferences
- Endpoints exchanging both live (camera) video and = presentation video (similar to H.239)
          Systems implementing multi-party conferences using a = full-mesh paradigm
Not = all of these scenarios are candidates for muxing at the transport layer, = so likely endpoints may need to be able to handle multiple RTP streams = anyway, which diminishes the appeal of RTP = muxing.
CTO, Avistar
From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org= ] On Behalf Of Peter = Musgrave
Sent: Saturday, January 29, 2011 = 2:33 PM
To:  clue@ietf.org
Subject: Re: [clue] Multiple Streams = - RTP muxing?
Please, no, not BOTH. I would = rather HAVE to do the one I like less than to do = both. 
Too many issues get left = as "do both" - and what results in interop chaos since even if both MUST = be done a vendor choses to emphasize one of the approaches in = their product and the other becomes a poor non-interoperable = cousin. 
Peter

On Sat, Jan 29, 2011 at = 4:28 PM, Aravind Sethuraman <aravind.sethuraman@teliris.com> = wrote:
Hi,

Is not transport level RTP muxing = and demuxing expensive on low end applications?
Can we not support = both RTP muxing and multiple m lines as part of the session = establishment?

Regards,
Aravind


--- lorenzo@meetecho.com wrote:

From: Lorenzo = Miniero <lorenzo@meetecho.com>
To: = Peter Musgrave <clue@ietf.org>
Subject: Re: [clue] Multiple = Streams - RTP muxing?
Date: Sat, 29 Jan 2011 09:35:16 = +0100


Well, if I have to think about a reason not to, = muxing/demuxing at an application level is surely less efficient than = doing it at a transport level. Besides, the RTP channel could get = "overloaded", which could be an issue with packet shapers/discarders (if = any).

But I guess that, if those you mentioned are the = advantages, that's not a real dealbreaker.

L.


On Sat, = 29 Jan 2011 02:51:52 -0500
Peter Musgrave <peter.musgrave@magorcorp.com> = wrote:

> All,
>
> CLUE needs to send multiple = audio and video streams between endpoints. TIP (see imtc.org) is an existing (somewhat limited) TP interop = protocol which made a decision to mux the multiple video data streams = into a single RTP flow (i.e. send all to the same destination port) = distinguishing them by SSRC id. Audio is treated = similarly.
>
> This has some significant advantages:
> = - middle boxes still see one video m-line and do not need to = change
> - ICE needs to run only once for the media stream
> = - encryption can cover all the payload with one key pair
>
> = The disadvantage is that there now needs to be a mapping of data to = logical RTP "channels" and this needs to be conveyed somehow. If this is = done in SDP then I would think mmusic work would be required to specify = it.
>
> I think the notion of a single, multiplexed video = stream for a TP endpoint makes a lot of sense in the context of = CLUE.
>
> Are there reasons not to mux?
>
> = Regards,
>
> Peter Musgrave
> = _______________________________________________
> clue mailing = list
> clue@ietf.org
>  



This email and any files transmitted with it are = confidential and intended solely for the use of the individual or entity = to whom they are addressed. 
If you are not the = intended recipient you are notified that disclosing, copying, = distributing or taking any action in reliance on the contents of this = information is strictly prohibited.
In-Reply-To: <20110129072842.CEF71BD6@resin11.mta.everyone.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] Multiple Streams - RTP muxing? Thread-Index: Acu/yUAQuNyIDoPeSfSDXzyE5I9InwAXBSKA References: <20110129072842.CEF71BD6@resin11.mta.everyone.net> From: "Allyn Romanow (allyn)" To: , "Lorenzo Miniero" X-OriginalArrivalTime: 30 Jan 2011 02:32:16.0139 (UTC) FILETIME=[E8BFADB0:01CBC025] 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: Sun, 30 Jan 2011 02:29:07 -0000 Hi Aravind,=20 Low end devices will have just a single stream in any case, and require something like a subset of composition to be sent to them. On other points, SDP allows multiple m-lines, but there is no agreed upon way to do the de-muxing, so I see that as where the work will be. It would probably require a new RTP profile or some other mechanism, so I think the work would be done in AVT. That said, it's certainly within scope for CLUE to discuss whether this is desirable/needed for telepresence. Regards, Allyn > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Aravind Sethuraman > Sent: Saturday, January 29, 2011 7:29 AM > To: Lorenzo Miniero > Cc: clue@ietf.org > Subject: Re: [clue] Multiple Streams - RTP muxing? >=20 > Hi, >=20 > Is not transport level RTP muxing and demuxing expensive on low end > applications? > Can we not support both RTP muxing and multiple m lines as part of the > session establishment? >=20 > Regards, > Aravind >=20 >=20 > --- lorenzo@meetecho.com wrote: >=20 > From: Lorenzo Miniero > To: Peter Musgrave > Cc: CLUE > Subject: Re: [clue] Multiple Streams - RTP muxing? > Date: Sat, 29 Jan 2011 09:35:16 +0100 >=20 > Well, if I have to think about a reason not to, muxing/demuxing at an > application level is surely less efficient than doing it at a transport > level. Besides, the RTP channel could get "overloaded", which could be > an issue with packet shapers/discarders (if any). >=20 > But I guess that, if those you mentioned are the advantages, that's not > a real dealbreaker. >=20 > L. >=20 >=20 > On Sat, 29 Jan 2011 02:51:52 -0500 > Peter Musgrave wrote: >=20 > > All, > > > > CLUE needs to send multiple audio and video streams between > endpoints. TIP (see imtc.org) is an existing (somewhat limited) TP > interop protocol which made a decision to mux the multiple video data > streams into a single RTP flow (i.e. send all to the same destination > port) distinguishing them by SSRC id. Audio is treated similarly. > > > > This has some significant advantages: > > - middle boxes still see one video m-line and do not need to change > > - ICE needs to run only once for the media stream > > - encryption can cover all the payload with one key pair > > > > The disadvantage is that there now needs to be a mapping of data to > logical RTP "channels" and this needs to be conveyed somehow. If this > is done in SDP then I would think mmusic work would be required to > specify it. > > > > I think the notion of a single, multiplexed video stream for a TP > endpoint makes a lot of sense in the context of CLUE. > > > > Are there reasons not to mux? > > > > Regards, > > > > Peter Musgrave > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue >=20 >=20 > -- > Lorenzo Miniero > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue >=20 >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From aravind.sethuraman@teliris.com Sun Jan 30 01:48:17 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 4F55A3A6939 for ; Sun, 30 Jan 2011 01:48:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.349 X-Spam-Level: X-Spam-Status: No, score=-3.349 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, 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 kq7tMAtiIhPk for ; Sun, 30 Jan 2011 01:48:16 -0800 (PST) Received: from imta-38.everyone.net (imta-35.everyone.net [216.200.145.35]) by core3.amsl.com (Postfix) with ESMTP id 168853A6938 for ; Sun, 30 Jan 2011 01:48:15 -0800 (PST) Received: from pps.filterd (omta001 [127.0.0.1]) by imta-38.everyone.net (8.14.4/8.14.4) with SMTP id p0U9pFNc028870; Sun, 30 Jan 2011 01:51:24 -0800 Received: from dm0227.mta.everyone.net (sj1-slb03-gw2.sj2.proofpoint.com [172.16.1.96]) by imta-38.everyone.net with ESMTP id u55f902s3-1; Sun, 30 Jan 2011 01:51:24 -0800 X-Eon-Dm: dm0227 Received: by dm0227.mta.everyone.net (EON-AUTHRELAY2 - 7aa4394f) id dm0227.4d4436cb.abed; Sun, 30 Jan 2011 01:51:12 -0800 X-Eon-Sig: AQLO6zJNRTSQcWUTGwIAAAAD,d4c9fa3ad62423232d15cca503cb3711 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: aravind sethuraman In-Reply-To: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC037267D3@xmb-sjc-221.amer.cisco.com> Date: Sun, 30 Jan 2011 04:51:13 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <594EFB8D-FFE8-4EEB-8063-F1AD8513BDC1@teliris.com> References: <20110129072842.CEF71BD6@resin11.mta.everyone.net> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC037267D3@xmb-sjc-221.amer.cisco.com> To: "Allyn Romanow (allyn)" X-Mailer: Apple Mail (2.1082) X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1012030000 definitions=main-1101300011 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: Sun, 30 Jan 2011 09:48:17 -0000 Allyn et al, Consider a case where a low end device, say ipad is in a "telepresence" = call with a 3 screen room..... there are 2 options to this,=20 either we send a single shot from the 3 screen room or we send the 3 = camera shot.... In case we chose to send 3 camera shot, If we opt for RTP Muxing, then = the process of demuxing on this low end appliance may be too expensive. either way, i think there should be an option of supporting either = multiple m lines or muxing as a session option. -aravind On Jan 29, 2011, at 9:32 PM, Allyn Romanow (allyn) wrote: > Hi Aravind,=20 > Low end devices will have just a single stream in any case, and = require > something like a subset of composition to be sent to them. >=20 > On other points, SDP allows multiple m-lines, but there is no agreed > upon way to do the de-muxing, so I see that as where the work will be. > It would probably require a new RTP profile or some other mechanism, = so > I think the work would be done in AVT. That said, it's certainly = within > scope for CLUE to discuss whether this is desirable/needed for > telepresence. >=20 > Regards, > Allyn >=20 >> -----Original Message----- >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf > Of >> Aravind Sethuraman >> Sent: Saturday, January 29, 2011 7:29 AM >> To: Lorenzo Miniero >> Cc: clue@ietf.org >> Subject: Re: [clue] Multiple Streams - RTP muxing? >>=20 >> Hi, >>=20 >> Is not transport level RTP muxing and demuxing expensive on low end >> applications? >> Can we not support both RTP muxing and multiple m lines as part of = the >> session establishment? >>=20 >> Regards, >> Aravind >>=20 >>=20 >> --- lorenzo@meetecho.com wrote: >>=20 >> From: Lorenzo Miniero >> To: Peter Musgrave >> Cc: CLUE >> Subject: Re: [clue] Multiple Streams - RTP muxing? >> Date: Sat, 29 Jan 2011 09:35:16 +0100 >>=20 >> Well, if I have to think about a reason not to, muxing/demuxing at an >> application level is surely less efficient than doing it at a > transport >> level. Besides, the RTP channel could get "overloaded", which could = be >> an issue with packet shapers/discarders (if any). >>=20 >> But I guess that, if those you mentioned are the advantages, that's > not >> a real dealbreaker. >>=20 >> L. >>=20 >>=20 >> On Sat, 29 Jan 2011 02:51:52 -0500 >> Peter Musgrave wrote: >>=20 >>> All, >>>=20 >>> CLUE needs to send multiple audio and video streams between >> endpoints. TIP (see imtc.org) is an existing (somewhat limited) TP >> interop protocol which made a decision to mux the multiple video data >> streams into a single RTP flow (i.e. send all to the same destination >> port) distinguishing them by SSRC id. Audio is treated similarly. >>>=20 >>> This has some significant advantages: >>> - middle boxes still see one video m-line and do not need to change >>> - ICE needs to run only once for the media stream >>> - encryption can cover all the payload with one key pair >>>=20 >>> The disadvantage is that there now needs to be a mapping of data to >> logical RTP "channels" and this needs to be conveyed somehow. If this >> is done in SDP then I would think mmusic work would be required to >> specify it. >>>=20 >>> I think the notion of a single, multiplexed video stream for a TP >> endpoint makes a lot of sense in the context of CLUE. >>>=20 >>> Are there reasons not to mux? >>>=20 >>> Regards, >>>=20 >>> Peter Musgrave >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >>=20 >>=20 >> -- >> Lorenzo Miniero >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >>=20 >>=20 >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue Aravind Sethuraman Software Architect Teliris, Inc. | 55 Broadway, 14th Floor, New York, NY 10006 | C = +1.917.355.0119 | O +1.212.490.1065 x1408 | F +1.212.269.2869 | AIM = aravindsraman From ron.even.tlv@gmail.com Sun Jan 30 02:41:05 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 42F923A693B for ; Sun, 30 Jan 2011 02:41:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, 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 jWqC89zarU+q for ; Sun, 30 Jan 2011 02:41:03 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 6BE3C3A6938 for ; Sun, 30 Jan 2011 02:41:03 -0800 (PST) Received: by wwa36 with SMTP id 36so5334602wwa.13 for ; Sun, 30 Jan 2011 02:44:14 -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:content-transfer-encoding :x-mailer:thread-index:content-language; bh=XX6lEvmvjO/2UwN1Rv9wTf5ctTdRt0NilNlZTARK0eY=; b=Clums5ymemmZgsnK1+Rd89e1Y6LEo2tc0hwjY+b0mEnLcm1f8Z1clo6hAKzqkl9Ub1 Yrgo5Kx6c3LZ6P25qMvTpMclh2a3PUdhnpvneTQcrhPVmWGMQT6Iz+zEQvO53tdn5CrI tzfp7EUHxHnm8DbLIyMjwnJXXmGrW0O2K/A7M= 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:content-transfer-encoding:x-mailer :thread-index:content-language; b=Ph/a2bFhexVhzHHoZrx3e/R/1LGDiiCsNeQTjqschJ192l6qprn9ysZqKQaK/nlKXB R50ldsYoBWlDMGRumJP1OXmruBHBv6lZRYEOz6BssF3VE1YQ6OOCuvvpzsYYSrrqlYga 5FDILeqt8Eez6u+D7CKc1r1VbPzS393OPs0Zs= Received: by 10.216.165.85 with SMTP id d63mr5035091wel.12.1296384253292; Sun, 30 Jan 2011 02:44:13 -0800 (PST) Received: from windows8d787f9 (bzq-109-64-31-233.red.bezeqint.net [109.64.31.233]) by mx.google.com with ESMTPS id u2sm7502938weh.36.2011.01.30.02.44.07 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 30 Jan 2011 02:44:11 -0800 (PST) From: "Roni Even" To: "'aravind sethuraman'" , "'Allyn Romanow \(allyn\)'" References: <20110129072842.CEF71BD6@resin11.mta.everyone.net> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC037267D3@xmb-sjc-221.amer.cisco.com> <594EFB8D-FFE8-4EEB-8063-F1AD8513BDC1@teliris.com> In-Reply-To: <594EFB8D-FFE8-4EEB-8063-F1AD8513BDC1@teliris.com> Date: Sun, 30 Jan 2011 12:39:47 +0200 Message-ID: <4d4540fb.027bd80a.187c.ffffebae@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvAY0YQO2xBR7xaTyCiOcQbT/qzQAABiEyw Content-Language: en-us 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: Sun, 30 Jan 2011 10:41:05 -0000 Hi, I think that the simple case is for the low end device to receive one stream. Receiving three multiplexed stream is not helpful without knowing what the streams are in order to have a meaningful display on the receiver. This will depend if the low end device will understand the multi-stream semantics that need to be specified in CLUE. To send the 3 camera shots the sender will need to know if the receiver can understand CLUE. Roni Even > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > aravind sethuraman > Sent: Sunday, January 30, 2011 11:51 AM > To: Allyn Romanow (allyn) > Cc: clue@ietf.org > Subject: Re: [clue] Multiple Streams - RTP muxing? > > Allyn et al, > Consider a case where a low end device, say ipad is in a "telepresence" > call with a 3 screen room..... > there are 2 options to this, > either we send a single shot from the 3 screen room or we send the 3 > camera shot.... > In case we chose to send 3 camera shot, If we opt for RTP Muxing, then > the process of demuxing on this low end appliance may be too expensive. > > either way, i think there should be an option of supporting either > multiple m lines or muxing as a session option. > > -aravind > > > > > On Jan 29, 2011, at 9:32 PM, Allyn Romanow (allyn) wrote: > > > Hi Aravind, > > Low end devices will have just a single stream in any case, and > require > > something like a subset of composition to be sent to them. > > > > On other points, SDP allows multiple m-lines, but there is no agreed > > upon way to do the de-muxing, so I see that as where the work will > be. > > It would probably require a new RTP profile or some other mechanism, > so > > I think the work would be done in AVT. That said, it's certainly > within > > scope for CLUE to discuss whether this is desirable/needed for > > telepresence. > > > > Regards, > > Allyn > > > >> -----Original Message----- > >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf > > Of > >> Aravind Sethuraman > >> Sent: Saturday, January 29, 2011 7:29 AM > >> To: Lorenzo Miniero > >> Cc: clue@ietf.org > >> Subject: Re: [clue] Multiple Streams - RTP muxing? > >> > >> Hi, > >> > >> Is not transport level RTP muxing and demuxing expensive on low end > >> applications? > >> Can we not support both RTP muxing and multiple m lines as part of > the > >> session establishment? > >> > >> Regards, > >> Aravind > >> > >> > >> --- lorenzo@meetecho.com wrote: > >> > >> From: Lorenzo Miniero > >> To: Peter Musgrave > >> Cc: CLUE > >> Subject: Re: [clue] Multiple Streams - RTP muxing? > >> Date: Sat, 29 Jan 2011 09:35:16 +0100 > >> > >> Well, if I have to think about a reason not to, muxing/demuxing at > an > >> application level is surely less efficient than doing it at a > > transport > >> level. Besides, the RTP channel could get "overloaded", which could > be > >> an issue with packet shapers/discarders (if any). > >> > >> But I guess that, if those you mentioned are the advantages, that's > > not > >> a real dealbreaker. > >> > >> L. > >> > >> > >> On Sat, 29 Jan 2011 02:51:52 -0500 > >> Peter Musgrave wrote: > >> > >>> All, > >>> > >>> CLUE needs to send multiple audio and video streams between > >> endpoints. TIP (see imtc.org) is an existing (somewhat limited) TP > >> interop protocol which made a decision to mux the multiple video > data > >> streams into a single RTP flow (i.e. send all to the same > destination > >> port) distinguishing them by SSRC id. Audio is treated similarly. > >>> > >>> This has some significant advantages: > >>> - middle boxes still see one video m-line and do not need to change > >>> - ICE needs to run only once for the media stream > >>> - encryption can cover all the payload with one key pair > >>> > >>> The disadvantage is that there now needs to be a mapping of data to > >> logical RTP "channels" and this needs to be conveyed somehow. If > this > >> is done in SDP then I would think mmusic work would be required to > >> specify it. > >>> > >>> I think the notion of a single, multiplexed video stream for a TP > >> endpoint makes a lot of sense in the context of CLUE. > >>> > >>> Are there reasons not to mux? > >>> > >>> Regards, > >>> > >>> Peter Musgrave > >>> _______________________________________________ > >>> clue mailing list > >>> clue@ietf.org > >>> https://www.ietf.org/mailman/listinfo/clue > >> > >> > >> -- > >> Lorenzo Miniero > >> _______________________________________________ > >> 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 > > Aravind Sethuraman > Software Architect > Teliris, Inc. | 55 Broadway, 14th Floor, New York, NY 10006 | C > +1.917.355.0119 | O +1.212.490.1065 x1408 | F +1.212.269.2869 | AIM > aravindsraman > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From stephen.botzko@gmail.com Sun Jan 30 03:54:34 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 693953A6947 for ; Sun, 30 Jan 2011 03:54:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.285 X-Spam-Level: X-Spam-Status: No, score=-3.285 tagged_above=-999 required=5 tests=[AWL=0.313, 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 4h9XdE0a8D-v for ; Sun, 30 Jan 2011 03:54:32 -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 294253A691D for ; Sun, 30 Jan 2011 03:54:31 -0800 (PST) Received: by vws7 with SMTP id 7so1721706vws.31 for ; Sun, 30 Jan 2011 03:57: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=DE94ovQ818/uV6lwQF4IIWzW6s9b8wT+W4rVl+Aj6Ic=; b=MmSNhqEGhWr0co++o7ubNc7MX19FghHvfcJD43R6W+w9NgCCrU5XY14Yx8n4U1be7d Rznipj8w6ZTP8kNNMB3O0YpRZzz/rU+I8qFr4O2981xgsC3iDuI1qSjOnKspZGOFXwRT RnokNo3JpgdN6y7KkLUd/AO8Xjk6YcMNv74Hw= 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=CuNOAki8lFYLXjycVoAGW8YMVcNnFHiO+30Le6UC5Jb04SRenN+qXcDM8iSMoIe1yN /2HYuRRSLREWwD6tasWP0nk3y+aYbQpS9zJfDVK1EXKN/HTC5A9GjJj+xPFwEREM4QdI n5/P7Ya9mqm36CQE5uGgpYao6fDXG+9iHAmRM= MIME-Version: 1.0 Received: by 10.220.199.8 with SMTP id eq8mr1310728vcb.78.1296388661890; Sun, 30 Jan 2011 03:57:41 -0800 (PST) Received: by 10.220.128.30 with HTTP; Sun, 30 Jan 2011 03:57:41 -0800 (PST) In-Reply-To: <4d4540fb.027bd80a.187c.ffffebae@mx.google.com> References: <20110129072842.CEF71BD6@resin11.mta.everyone.net> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC037267D3@xmb-sjc-221.amer.cisco.com> <594EFB8D-FFE8-4EEB-8063-F1AD8513BDC1@teliris.com> <4d4540fb.027bd80a.187c.ffffebae@mx.google.com> Date: Sun, 30 Jan 2011 06:57:41 -0500 Message-ID: From: Stephen Botzko To: Roni Even Content-Type: multipart/alternative; boundary=90e6ba53a8b8aed02a049b0f01c6 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: Sun, 30 Jan 2011 11:54:34 -0000 --90e6ba53a8b8aed02a049b0f01c6 Content-Type: text/plain; charset=ISO-8859-1 I agree. The CLUE device needs to signal a single-stream m line in any case, otherwise there is no compatibility with existing videoconferencing. (Actually it will need to offer two legacy streams, since existing videoconferencing supports presentation video along with the room video). Accepting the offer for the traditional m-line results in getting a single stream (perhaps full room, or perhaps center camera). The CLUE device also needs to offer multi-stream CLUE in some fashion - whatever mechanism we use has to result in the legacy endpoint not accepting the CLUE offer(s). This could possibly be done in the initial SDP, or it could be done in a second-phase negotiation somehow. Offering CLUE streams in 2 forms (multiplexed and not multiplexed) results in 3 sets of stream offers for video - legacy, CLUE multiplexed, and CLUE non-multiplexed; and probably another 3 sets for the audio. Like Peter, I don't want to do this both ways. I don't think the hypothetical low-end endpoint that is (a) not legacy single stream, (b) understands CLUE, (c) can encode/ decode multiple CLUE streams, (d) cannot do the RTP multiplexing is real. If there's consensus that it is real, then we need to drop the multiplexing idea. Though personally I'd like to hear more justification on why this actually very capable device has this surprising limitation. Regards Stephen Botzko On Sun, Jan 30, 2011 at 5:39 AM, Roni Even wrote: > Hi, > I think that the simple case is for the low end device to receive one > stream. Receiving three multiplexed stream is not helpful without knowing > what the streams are in order to have a meaningful display on the receiver. > This will depend if the low end device will understand the multi-stream > semantics that need to be specified in CLUE. > To send the 3 camera shots the sender will need to know if the receiver can > understand CLUE. > > Roni Even > > > -----Original Message----- > > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > > aravind sethuraman > > Sent: Sunday, January 30, 2011 11:51 AM > > To: Allyn Romanow (allyn) > > Cc: clue@ietf.org > > Subject: Re: [clue] Multiple Streams - RTP muxing? > > > > Allyn et al, > > Consider a case where a low end device, say ipad is in a "telepresence" > > call with a 3 screen room..... > > there are 2 options to this, > > either we send a single shot from the 3 screen room or we send the 3 > > camera shot.... > > In case we chose to send 3 camera shot, If we opt for RTP Muxing, then > > the process of demuxing on this low end appliance may be too expensive. > > > > either way, i think there should be an option of supporting either > > multiple m lines or muxing as a session option. > > > > -aravind > > > > > > > > > > On Jan 29, 2011, at 9:32 PM, Allyn Romanow (allyn) wrote: > > > > > Hi Aravind, > > > Low end devices will have just a single stream in any case, and > > require > > > something like a subset of composition to be sent to them. > > > > > > On other points, SDP allows multiple m-lines, but there is no agreed > > > upon way to do the de-muxing, so I see that as where the work will > > be. > > > It would probably require a new RTP profile or some other mechanism, > > so > > > I think the work would be done in AVT. That said, it's certainly > > within > > > scope for CLUE to discuss whether this is desirable/needed for > > > telepresence. > > > > > > Regards, > > > Allyn > > > > > >> -----Original Message----- > > >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf > > > Of > > >> Aravind Sethuraman > > >> Sent: Saturday, January 29, 2011 7:29 AM > > >> To: Lorenzo Miniero > > >> Cc: clue@ietf.org > > >> Subject: Re: [clue] Multiple Streams - RTP muxing? > > >> > > >> Hi, > > >> > > >> Is not transport level RTP muxing and demuxing expensive on low end > > >> applications? > > >> Can we not support both RTP muxing and multiple m lines as part of > > the > > >> session establishment? > > >> > > >> Regards, > > >> Aravind > > >> > > >> > > >> --- lorenzo@meetecho.com wrote: > > >> > > >> From: Lorenzo Miniero > > >> To: Peter Musgrave > > >> Cc: CLUE > > >> Subject: Re: [clue] Multiple Streams - RTP muxing? > > >> Date: Sat, 29 Jan 2011 09:35:16 +0100 > > >> > > >> Well, if I have to think about a reason not to, muxing/demuxing at > > an > > >> application level is surely less efficient than doing it at a > > > transport > > >> level. Besides, the RTP channel could get "overloaded", which could > > be > > >> an issue with packet shapers/discarders (if any). > > >> > > >> But I guess that, if those you mentioned are the advantages, that's > > > not > > >> a real dealbreaker. > > >> > > >> L. > > >> > > >> > > >> On Sat, 29 Jan 2011 02:51:52 -0500 > > >> Peter Musgrave wrote: > > >> > > >>> All, > > >>> > > >>> CLUE needs to send multiple audio and video streams between > > >> endpoints. TIP (see imtc.org) is an existing (somewhat limited) TP > > >> interop protocol which made a decision to mux the multiple video > > data > > >> streams into a single RTP flow (i.e. send all to the same > > destination > > >> port) distinguishing them by SSRC id. Audio is treated similarly. > > >>> > > >>> This has some significant advantages: > > >>> - middle boxes still see one video m-line and do not need to change > > >>> - ICE needs to run only once for the media stream > > >>> - encryption can cover all the payload with one key pair > > >>> > > >>> The disadvantage is that there now needs to be a mapping of data to > > >> logical RTP "channels" and this needs to be conveyed somehow. If > > this > > >> is done in SDP then I would think mmusic work would be required to > > >> specify it. > > >>> > > >>> I think the notion of a single, multiplexed video stream for a TP > > >> endpoint makes a lot of sense in the context of CLUE. > > >>> > > >>> Are there reasons not to mux? > > >>> > > >>> Regards, > > >>> > > >>> Peter Musgrave > > >>> _______________________________________________ > > >>> clue mailing list > > >>> clue@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/clue > > >> > > >> > > >> -- > > >> Lorenzo Miniero > > >> _______________________________________________ > > >> 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 > > > > Aravind Sethuraman > > Software Architect > > Teliris, Inc. | 55 Broadway, 14th Floor, New York, NY 10006 | C > > +1.917.355.0119 | O +1.212.490.1065 x1408 | F +1.212.269.2869 | AIM > > aravindsraman > > > > > > _______________________________________________ > > 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 > --90e6ba53a8b8aed02a049b0f01c6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I agree.=A0 The CLUE device needs to signal a single-stream m line in any c= ase, otherwise there is no compatibility with existing videoconferencing. (= Actually it will need to offer two legacy streams, since existing videoconf= erencing supports presentation video along with the room video). Accepting = the offer for the traditional m-line results in getting a single stream (pe= rhaps full room, or perhaps center camera).

The CLUE device also needs to offer multi-stream CLUE in some fashion -= whatever mechanism we use has to result in the legacy endpoint not accepti= ng the CLUE offer(s).=A0 This could possibly be done in the initial SDP, or= it could be done in a second-phase negotiation somehow.

Offering CLUE streams in 2 forms (multiplexed and not multiplexed) resu= lts in 3 sets of stream offers for video - legacy, CLUE multiplexed, and CL= UE non-multiplexed; and probably another 3 sets for the audio.=A0

Like Peter, I don't want to do this both ways. I don't think the hy= pothetical low-end endpoint that is (a) not legacy single stream, (b) under= stands CLUE, (c) can encode/ decode multiple CLUE streams, (d) cannot do th= e RTP multiplexing is real.=A0 If there's consensus that it is real, th= en we need to drop the multiplexing idea.=A0 Though personally I'd like= to hear more justification on why this actually very capable device has th= is surprising limitation.

Regards
Stephen Botzko


On Sun,= Jan 30, 2011 at 5:39 AM, Roni Even <ron.even.tlv@gmail.com> wrote:
Hi,
I think that the simple case is for the low end device to receive one
stream. Receiving three multiplexed stream is not helpful without knowing what the streams are in order to have a meaningful display on the receiver.=
This will depend if the low end device will understand the multi-stream
semantics that need to be specified in CLUE.
To send the 3 camera shots the sender will need to know if the receiver can=
understand CLUE.

Roni Even

> -----Original Message-----
> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of
> aravind sethuraman
> Sent: Sunday, January 30, 2011 11:51 AM
> To: Allyn Romanow (allyn)
> Cc: clue@ietf.org
> Subject: Re: [clue] Multiple Streams - RTP muxing?
>
> Allyn et al,
> Consider a case where a low end device, say ipad is in a "telepre= sence"
> call with a 3 screen room.....
> there are 2 options to this,
> either we send a single shot from the 3 screen room or we send the 3 > camera shot....
> In case we chose to send 3 camera shot, If we opt for RTP Muxing, then=
> the process of demuxing on this low end appliance may be too expensive= .
>
> either way, i think there should be an option of =A0supporting either<= br> > multiple m lines or muxing as a session option.
>
> -aravind
>
>
>
>
> On Jan 29, 2011, at 9:32 PM, Allyn Romanow (allyn) wrote:
>
> > Hi Aravind,
> > Low end devices will have just a single stream in any case, and > require
> > something like a subset of composition to be sent to them.
> >
> > On other points, SDP allows multiple m-lines, but there is no agr= eed
> > upon way to do the de-muxing, so I see that as where the work wil= l
> be.
> > It would probably require a new RTP profile or some other mechani= sm,
> so
> > I think the work would be done in AVT. That said, it's certai= nly
> within
> > scope for CLUE to discuss whether this is desirable/needed for > > telepresence.
> >
> > Regards,
> > Allyn
> >
> >> -----Original Message-----
> >> From: clue-bounces@i= etf.org [mailto:clue-bounces@i= etf.org] On Behalf
> > Of
> >> Aravind Sethuraman
> >> Sent: Saturday, January 29, 2011 7:29 AM
> >> To: Lorenzo Miniero
> >> Cc: clue@ietf.org
> >> Subject: Re: [clue] Multiple Streams - RTP muxing?
> >>
> >> Hi,
> >>
> >> Is not transport level RTP muxing and demuxing expensive on l= ow end
> >> applications?
> >> Can we not support both RTP muxing and multiple m lines as pa= rt of
> the
> >> session establishment?
> >>
> >> Regards,
> >> Aravind
> >>
> >>
> >> --- lorenzo@meetecho.= com wrote:
> >>
> >> From: Lorenzo Miniero <lorenzo@meetecho.com>
> >> To: Peter Musgrave <peter.musgrave@magorcorp.com>
> >> Cc: CLUE <clue@ietf.org>
> >> Subject: Re: [clue] Multiple Streams - RTP muxing?
> >> Date: Sat, 29 Jan 2011 09:35:16 +0100
> >>
> >> Well, if I have to think about a reason not to, muxing/demuxi= ng at
> an
> >> application level is surely less efficient than doing it at a=
> > transport
> >> level. Besides, the RTP channel could get "overloaded&qu= ot;, which could
> be
> >> an issue with packet shapers/discarders (if any).
> >>
> >> But I guess that, if those you mentioned are the advantages, = that's
> > not
> >> a real dealbreaker.
> >>
> >> L.
> >>
> >>
> >> On Sat, 29 Jan 2011 02:51:52 -0500
> >> Peter Musgrave <peter.musgrave@magorcorp.com> wrote:
> >>
> >>> All,
> >>>
> >>> CLUE needs to send multiple audio and video streams betwe= en
> >> endpoints. TIP (see imtc.org) is an existing (somewhat limited) TP
> >> interop protocol which made a decision to mux the multiple vi= deo
> data
> >> streams into a single RTP flow (i.e. send all to the same
> destination
> >> port) distinguishing them by SSRC id. Audio is treated simila= rly.
> >>>
> >>> This has some significant advantages:
> >>> - middle boxes still see one video m-line and do not need= to change
> >>> - ICE needs to run only once for the media stream
> >>> - encryption can cover all the payload with one key pair<= br> > >>>
> >>> The disadvantage is that there now needs to be a mapping = of data to
> >> logical RTP "channels" and this needs to be conveye= d somehow. If
> this
> >> is done in SDP then I would think mmusic work would be requir= ed to
> >> specify it.
> >>>
> >>> I think the notion of a single, multiplexed video stream = for a TP
> >> endpoint makes a lot of sense in the context of CLUE.
> >>>
> >>> Are there reasons not to mux?
> >>>
> >>> Regards,
> >>>
> >>> Peter Musgrave
> >>> _______________________________________________
> >>> clue mailing list
> >>> clue@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/clue
> >>
> >>
> >> --
> >> Lorenzo Miniero <l= orenzo@meetecho.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
>
> Aravind Sethuraman
> Software Architect
> Teliris, Inc. | 55 Broadway, 14th Floor, New York, NY 10006 | C
> +1.917.355.0119 | O +1.212.490.1065 x1408 | F +1.212.269.2869 | AIM > aravindsraman
>
>
> _______________________________________________
> clue mailing list
> clue@ietf.org
> https://www.ietf.org/mailman/listinfo/clue

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

--90e6ba53a8b8aed02a049b0f01c6-- From allyn@cisco.com Sun Jan 30 14:29: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 6F91D3A6881 for ; Sun, 30 Jan 2011 14:29:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.529 X-Spam-Level: X-Spam-Status: No, score=-10.529 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 BTndotp3XD9C for ; Sun, 30 Jan 2011 14:29:02 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 367253A6849 for ; Sun, 30 Jan 2011 14:29:02 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvQFAK91RU2rR7Hu/2dsb2JhbACCQpNShkcBiBhznluaHYMRgj0EhROKWYMR Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 30 Jan 2011 22:32:14 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id p0UMWEdZ003567; Sun, 30 Jan 2011 22:32:14 GMT Received: from xmb-sjc-221.amer.cisco.com ([128.107.191.80]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 30 Jan 2011 14:32:14 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 x-cr-hashedpuzzle: A2Z/ BqS6 FvK2 FwPD JtrF NqJt SDVT UfnL ZPZL cF/6 dPBF iIWO qRWI swKF vg3k wOKl; 4; YQByAGEAdgBpAG4AZAAuAHMAZQB0AGgAdQByAGEAbQBhAG4AQAB0AGUAbABpAHIAaQBzAC4AYwBvAG0AOwBjAGwAdQBlAEAAaQBlAHQAZgAuAG8AcgBnADsAcgBvAG4ALgBlAHYAZQBuAC4AdABsAHYAQABnAG0AYQBpAGwALgBjAG8AbQA7AHMAdABlAHAAaABlAG4ALgBiAG8AdAB6AGsAbwBAAGcAbQBhAGkAbAAuAGMAbwBtAA==; Sosha1_v1; 7; {119F7A17-FD14-4739-8B6F-55D9B439597B}; YQBsAGwAeQBuAEAAYwBpAHMAYwBvAC4AYwBvAG0A; Sun, 30 Jan 2011 22:31:54 GMT; UgBFADoAIABbAGMAbAB1AGUAXQAgAE0AdQBsAHQAaQBwAGwAZQAgAFMAdAByAGUAYQBtAHMAIAAtACAAUgBUAFAAIABtAHUAeABpAG4AZwA/AA== MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBC0CD.8AF39476" x-cr-puzzleid: {119F7A17-FD14-4739-8B6F-55D9B439597B} Content-class: urn:content-classes:message Date: Sun, 30 Jan 2011 14:31:54 -0800 Message-ID: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC0372684C@xmb-sjc-221.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] Multiple Streams - RTP muxing? Thread-Index: AcvAdOhulHe279yjREe4psCOedoyWQAWGppQ References: <20110129072842.CEF71BD6@resin11.mta.everyone.net><9AC2C4348FD86B4BB1F8FA9C5E3A5EDC037267D3@xmb-sjc-221.amer.cisco.com><594EFB8D-FFE8-4EEB-8063-F1AD8513BDC1@teliris.com><4d4540fb.027bd80a.187c.ffffebae@mx.google.com> From: "Allyn Romanow (allyn)" To: "Stephen Botzko" , "Roni Even" X-OriginalArrivalTime: 30 Jan 2011 22:32:14.0590 (UTC) FILETIME=[8B2B71E0:01CBC0CD] 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: Sun, 30 Jan 2011 22:29:04 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBC0CD.8AF39476 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yeah, I agree with you Steve and Roni- =20 From: Stephen Botzko [mailto:stephen.botzko@gmail.com]=20 Sent: Sunday, January 30, 2011 3:58 AM To: Roni Even Cc: aravind sethuraman; Allyn Romanow (allyn); clue@ietf.org Subject: Re: [clue] Multiple Streams - RTP muxing? =20 I agree. The CLUE device needs to signal a single-stream m line in any case, otherwise there is no compatibility with existing videoconferencing. (Actually it will need to offer two legacy streams, since existing videoconferencing supports presentation video along with the room video). Accepting the offer for the traditional m-line results in getting a single stream (perhaps full room, or perhaps center camera). The CLUE device also needs to offer multi-stream CLUE in some fashion - whatever mechanism we use has to result in the legacy endpoint not accepting the CLUE offer(s). This could possibly be done in the initial SDP, or it could be done in a second-phase negotiation somehow. Offering CLUE streams in 2 forms (multiplexed and not multiplexed) results in 3 sets of stream offers for video - legacy, CLUE multiplexed, and CLUE non-multiplexed; and probably another 3 sets for the audio. =20 Like Peter, I don't want to do this both ways. I don't think the hypothetical low-end endpoint that is (a) not legacy single stream, (b) understands CLUE, (c) can encode/ decode multiple CLUE streams, (d) cannot do the RTP multiplexing is real. If there's consensus that it is real, then we need to drop the multiplexing idea. Though personally I'd like to hear more justification on why this actually very capable device has this surprising limitation. Regards Stephen Botzko On Sun, Jan 30, 2011 at 5:39 AM, Roni Even wrote: Hi, I think that the simple case is for the low end device to receive one stream. Receiving three multiplexed stream is not helpful without knowing what the streams are in order to have a meaningful display on the receiver. This will depend if the low end device will understand the multi-stream semantics that need to be specified in CLUE. To send the 3 camera shots the sender will need to know if the receiver can understand CLUE. Roni Even > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > aravind sethuraman > Sent: Sunday, January 30, 2011 11:51 AM > To: Allyn Romanow (allyn) > Cc: clue@ietf.org > Subject: Re: [clue] Multiple Streams - RTP muxing? > > Allyn et al, > Consider a case where a low end device, say ipad is in a "telepresence" > call with a 3 screen room..... > there are 2 options to this, > either we send a single shot from the 3 screen room or we send the 3 > camera shot.... > In case we chose to send 3 camera shot, If we opt for RTP Muxing, then > the process of demuxing on this low end appliance may be too expensive. > > either way, i think there should be an option of supporting either > multiple m lines or muxing as a session option. > > -aravind > > > > > On Jan 29, 2011, at 9:32 PM, Allyn Romanow (allyn) wrote: > > > Hi Aravind, > > Low end devices will have just a single stream in any case, and > require > > something like a subset of composition to be sent to them. > > > > On other points, SDP allows multiple m-lines, but there is no agreed > > upon way to do the de-muxing, so I see that as where the work will > be. > > It would probably require a new RTP profile or some other mechanism, > so > > I think the work would be done in AVT. That said, it's certainly > within > > scope for CLUE to discuss whether this is desirable/needed for > > telepresence. > > > > Regards, > > Allyn > > > >> -----Original Message----- > >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf > > Of > >> Aravind Sethuraman > >> Sent: Saturday, January 29, 2011 7:29 AM > >> To: Lorenzo Miniero > >> Cc: clue@ietf.org > >> Subject: Re: [clue] Multiple Streams - RTP muxing? > >> > >> Hi, > >> > >> Is not transport level RTP muxing and demuxing expensive on low end > >> applications? > >> Can we not support both RTP muxing and multiple m lines as part of > the > >> session establishment? > >> > >> Regards, > >> Aravind > >> > >> > >> --- lorenzo@meetecho.com wrote: > >> > >> From: Lorenzo Miniero > >> To: Peter Musgrave > >> Cc: CLUE > >> Subject: Re: [clue] Multiple Streams - RTP muxing? > >> Date: Sat, 29 Jan 2011 09:35:16 +0100 > >> > >> Well, if I have to think about a reason not to, muxing/demuxing at > an > >> application level is surely less efficient than doing it at a > > transport > >> level. Besides, the RTP channel could get "overloaded", which could > be > >> an issue with packet shapers/discarders (if any). > >> > >> But I guess that, if those you mentioned are the advantages, that's > > not > >> a real dealbreaker. > >> > >> L. > >> > >> > >> On Sat, 29 Jan 2011 02:51:52 -0500 > >> Peter Musgrave wrote: > >> > >>> All, > >>> > >>> CLUE needs to send multiple audio and video streams between > >> endpoints. TIP (see imtc.org) is an existing (somewhat limited) TP > >> interop protocol which made a decision to mux the multiple video > data > >> streams into a single RTP flow (i.e. send all to the same > destination > >> port) distinguishing them by SSRC id. Audio is treated similarly. > >>> > >>> This has some significant advantages: > >>> - middle boxes still see one video m-line and do not need to change > >>> - ICE needs to run only once for the media stream > >>> - encryption can cover all the payload with one key pair > >>> > >>> The disadvantage is that there now needs to be a mapping of data to > >> logical RTP "channels" and this needs to be conveyed somehow. If > this > >> is done in SDP then I would think mmusic work would be required to > >> specify it. > >>> > >>> I think the notion of a single, multiplexed video stream for a TP > >> endpoint makes a lot of sense in the context of CLUE. > >>> > >>> Are there reasons not to mux? > >>> > >>> Regards, > >>> > >>> Peter Musgrave > >>> _______________________________________________ > >>> clue mailing list > >>> clue@ietf.org > >>> https://www.ietf.org/mailman/listinfo/clue > >> > >> > >> -- > >> Lorenzo Miniero > >> _______________________________________________ > >> 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 > > Aravind Sethuraman > Software Architect > Teliris, Inc. | 55 Broadway, 14th Floor, New York, NY 10006 | C > +1.917.355.0119 | O +1.212.490.1065 x1408 | F +1.212.269.2869 | AIM > aravindsraman > > > _______________________________________________ > 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 ------_=_NextPart_001_01CBC0CD.8AF39476 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Yeah, I agree with you Steve and = Roni-

 

From:= Stephen = Botzko [mailto:stephen.botzko@gmail.com]
Sent: Sunday, January 30, 2011 3:58 AM
To: Roni Even
Cc: aravind sethuraman; Allyn Romanow (allyn); clue@ietf.org
Subject: Re: [clue] Multiple Streams - RTP = muxing?

 

I agree.  The = CLUE device needs to signal a single-stream m line in any case, otherwise there is = no compatibility with existing videoconferencing. (Actually it will need to = offer two legacy streams, since existing videoconferencing supports = presentation video along with the room video). Accepting the offer for the = traditional m-line results in getting a single stream (perhaps full room, or perhaps = center camera).

The CLUE device also needs to offer multi-stream CLUE in some fashion - whatever mechanism we use has to result in the legacy endpoint not = accepting the CLUE offer(s).  This could possibly be done in the initial SDP, = or it could be done in a second-phase negotiation somehow.

Offering CLUE streams in 2 forms (multiplexed and not multiplexed) = results in 3 sets of stream offers for video - legacy, CLUE multiplexed, and CLUE non-multiplexed; and probably another 3 sets for the audio. 

Like Peter, I don't want to do this both ways. I don't think the = hypothetical low-end endpoint that is (a) not legacy single stream, (b) understands = CLUE, (c) can encode/ decode multiple CLUE streams, (d) cannot do the RTP multiplexing is real.  If there's consensus that it is real, then = we need to drop the multiplexing idea.  Though personally I'd like to hear = more justification on why this actually very capable device has this = surprising limitation.

Regards
Stephen Botzko

On Sun, Jan 30, 2011 at 5:39 AM, Roni Even <ron.even.tlv@gmail.com> = wrote:

Hi,
I think that the simple case is for the low end device to receive = one
stream. Receiving three multiplexed stream is not helpful without = knowing
what the streams are in order to have a meaningful display on the = receiver.
This will depend if the low end device will understand the = multi-stream
semantics that need to be specified in CLUE.
To send the 3 camera shots the sender will need to know if the receiver = can
understand CLUE.

Roni Even


> -----Original Message-----
> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of

> aravind sethuraman
> Sent: Sunday, January 30, 2011 11:51 AM
> To: Allyn Romanow (allyn)
> Cc: clue@ietf.org
> Subject: Re: [clue] Multiple Streams - RTP muxing?
>
> Allyn et al,
> Consider a case where a low end device, say ipad is in a "telepresence"
> call with a 3 screen room.....
> there are 2 options to this,
> either we send a single shot from the 3 screen room or we send the = 3
> camera shot....
> In case we chose to send 3 camera shot, If we opt for RTP Muxing, = then
> the process of demuxing on this low end appliance may be too = expensive.
>
> either way, i think there should be an option of  supporting = either
> multiple m lines or muxing as a session option.
>
> -aravind
>
>
>
>
> On Jan 29, 2011, at 9:32 PM, Allyn Romanow (allyn) wrote:
>
> > Hi Aravind,
> > Low end devices will have just a single stream in any case, = and
> require
> > something like a subset of composition to be sent to them.
> >
> > On other points, SDP allows multiple m-lines, but there is no = agreed
> > upon way to do the de-muxing, so I see that as where the work = will
> be.
> > It would probably require a new RTP profile or some other = mechanism,
> so
> > I think the work would be done in AVT. That said, it's = certainly
> within
> > scope for CLUE to discuss whether this is desirable/needed = for
> > telepresence.
> >
> > Regards,
> > Allyn
> >
> >> -----Original Message-----
> >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf
> > Of
> >> Aravind Sethuraman
> >> Sent: Saturday, January 29, 2011 7:29 AM
> >> To: Lorenzo Miniero
> >> Cc: clue@ietf.org
> >> Subject: Re: [clue] Multiple Streams - RTP muxing?
> >>
> >> Hi,
> >>
> >> Is not transport level RTP muxing and demuxing expensive = on low end
> >> applications?
> >> Can we not support both RTP muxing and multiple m lines as = part of
> the
> >> session establishment?
> >>
> >> Regards,
> >> Aravind
> >>
> >>
> >> --- lorenzo@meetecho.com wrote:
> >>
> >> From: Lorenzo Miniero <lorenzo@meetecho.com>
> >> To: Peter Musgrave <peter.musgrave@magorcorp.com= >
> >> Cc: CLUE <clue@ietf.org>
> >> Subject: Re: [clue] Multiple Streams - RTP muxing?
> >> Date: Sat, 29 Jan 2011 09:35:16 +0100
> >>
> >> Well, if I have to think about a reason not to, = muxing/demuxing at
> an
> >> application level is surely less efficient than doing it = at a
> > transport
> >> level. Besides, the RTP channel could get = "overloaded", which could
> be
> >> an issue with packet shapers/discarders (if any).
> >>
> >> But I guess that, if those you mentioned are the = advantages, that's
> > not
> >> a real dealbreaker.
> >>
> >> L.
> >>
> >>
> >> On Sat, 29 Jan 2011 02:51:52 -0500
> >> Peter Musgrave <peter.musgrave@magorcorp.com= > wrote:
> >>
> >>> All,
> >>>
> >>> CLUE needs to send multiple audio and video streams = between
> >> endpoints. TIP (see imtc.org) is an existing (somewhat limited) TP
> >> interop protocol which made a decision to mux the multiple = video
> data
> >> streams into a single RTP flow (i.e. send all to the = same
> destination
> >> port) distinguishing them by SSRC id. Audio is treated = similarly.
> >>>
> >>> This has some significant advantages:
> >>> - middle boxes still see one video m-line and do not = need to change
> >>> - ICE needs to run only once for the media stream
> >>> - encryption can cover all the payload with one key = pair
> >>>
> >>> The disadvantage is that there now needs to be a = mapping of data to
> >> logical RTP "channels" and this needs to be = conveyed somehow. If
> this
> >> is done in SDP then I would think mmusic work would be = required to
> >> specify it.
> >>>
> >>> I think the notion of a single, multiplexed video = stream for a TP
> >> endpoint makes a lot of sense in the context of CLUE.
> >>>
> >>> Are there reasons not to mux?
> >>>
> >>> Regards,
> >>>
> >>> Peter Musgrave
> >>> _______________________________________________
> >>> clue mailing list
> >>> clue@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/clue
> >>
> >>
> >> --
> >> Lorenzo Miniero <lorenzo@meetecho.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
>
> Aravind Sethuraman
> Software Architect
> Teliris, Inc. | 55 Broadway, 14th Floor, New York, NY 10006 | C
> +1.917.355.0119 | O +1.212.490.1065 x1408 | F +1.212.269.2869 | = AIM
> aravindsraman
>
>
> _______________________________________________
> 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

 

------_=_NextPart_001_01CBC0CD.8AF39476-- From allyn@cisco.com Sun Jan 30 16:26: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 9D90F3A68EA for ; Sun, 30 Jan 2011 16:26:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.533 X-Spam-Level: X-Spam-Status: No, score=-10.533 tagged_above=-999 required=5 tests=[AWL=0.066, 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 QwCRhDXAWBzT for ; Sun, 30 Jan 2011 16:26:57 -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 E1B8B3A68BF for ; Sun, 30 Jan 2011 16:26:57 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Al4EABqRRU2rR7H+/2dsb2JhbACEFZIAP40zbnOeXopijzqBI4M3dASFE4pZgxE Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-4.cisco.com with ESMTP; 31 Jan 2011 00:30:10 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p0V0UAoY015801; Mon, 31 Jan 2011 00:30:10 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); Sun, 30 Jan 2011 16:30:10 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Sun, 30 Jan 2011 16:30:09 -0800 Message-ID: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC03726863@xmb-sjc-221.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-romanow-clue-telepresence-use-cases-01 - new use case - heterogeneous devices Thread-Index: AcvA2Uk2SKIMVnZcS8a/MuvjqOmD+wAA/TtQ From: "Allyn Romanow (allyn)" To: X-OriginalArrivalTime: 31 Jan 2011 00:30:10.0738 (UTC) FILETIME=[04E1F120:01CBC0DE] Cc: Gonzalo Camarillo Subject: [clue] draft-romanow-clue-telepresence-use-cases-01 - new use case - heterogeneous devices 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, 31 Jan 2011 00:26:58 -0000 Rm9sa3MsIEkndmUgc3VibWl0dGVkIGEgbmV3IHZlcnNpb24gb2YgdGhlIFVzZSBDYXNlIGRyYWZ0 LiBJIGFkZGVkIHNlY3Rpb24gNC41IHdoaWNoIGNvdmVycyB0aGUgY2FzZSBvZiBoZXRlcm9nZW5l b3VzIGRldmljZXMgcGFydGljaXBhdGluZyBpbiB0aGUgY29uZmVyZW5jZS4NCg0KRmVlZGJhY2sg b24gdGhlIHVzZSBjYXNlcywgbW9zdCB3ZWxjb21lISEhDQoNClRoYW5rcywNCkFsbHluDQoNCi0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBJRVRGIEktRCBTdWJtaXNzaW9uIFRvb2wg W21haWx0bzppZHN1Ym1pc3Npb25AaWV0Zi5vcmddIA0KU2VudDogU3VuZGF5LCBKYW51YXJ5IDMw LCAyMDExIDM6NTMgUE0NClRvOiBBbGx5biBSb21hbm93IChhbGx5bikNCkNjOiBzdGVwaGVuLmJv dHprb0Bwb2x5Y29tLmNvbTsgbWFyay5kdWNrd29ydGhAcG9seWNvbS5jb207IHJvbi5ldmVuLnRs dkBnbWFpbC5jb207IG1hcnNoYWxsLmV1YmFua3NAaWxmb3JtYXRhLmNvbQ0KU3ViamVjdDogTmV3 IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1yb21hbm93LWNsdWUtdGVsZXByZXNlbmNl LXVzZS1jYXNlcy0wMSANCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtcm9tYW5vdy1j bHVlLXRlbGVwcmVzZW5jZS11c2UtY2FzZXMtMDEudHh0IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBz dWJtaXR0ZWQgYnkgQWxseW4gUm9tYW5vdyBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRv cnkuDQoNCkZpbGVuYW1lOgkgZHJhZnQtcm9tYW5vdy1jbHVlLXRlbGVwcmVzZW5jZS11c2UtY2Fz ZXMNClJldmlzaW9uOgkgMDENClRpdGxlOgkJIFVzZSBDYXNlcyBmb3IgVGVsZXByZXNlbmNlIE11 bHRpLXN0cmVhbXMNCkNyZWF0aW9uX2RhdGU6CSAyMDExLTAxLTMxDQpXRyBJRDoJCSBJbmRlcGVu ZGVudCBTdWJtaXNzaW9uDQpOdW1iZXJfb2ZfcGFnZXM6IDE1DQoNCkFic3RyYWN0Og0KVGVsZXBy ZXNlbmNlIGNvbmZlcmVuY2luZyBzeXN0ZW1zIHNlZWsgdG8gY3JlYXRlIHRoZSBzZW5zZSBvZiBy ZWFsbHkNCmJlaW5nIHByZXNlbnQuICBBIG51bWJlciBvZiB0ZWNobmlxdWVzIGZvciBoYW5kbGlu ZyBhdWRpbyBhbmQgdmlkZW8NCnN0cmVhbXMgYXJlIHVzZWQgdG8gY3JlYXRlIHRoaXMgZXhwZXJp ZW5jZS4gIFdoZW4gdGhlc2UgdGVjaG5pcXVlcw0KYXJlIG5vdCBzaW1pbGFyLCBpbnRlcm9wZXJh YmlsaXR5IGJldHdlZW4gZGlmZmVyZW50IHN5c3RlbXMgaXMNCmRpZmZpY3VsdCBhdCBiZXN0LCBh bmQgb2Z0ZW4gbm90IHBvc3NpYmxlLiAgQ29udmV5aW5nIGluZm9ybWF0aW9uDQphYm91dCB0aGUg cmVsYXRpb25zaGlwcyBiZXR3ZWVuIG11bHRpcGxlIHN0cmVhbXMgb2YgbWVkaWEgd291bGQgYWxs b3cNCnNlbmRlcnMgYW5kIHJlY2VpdmVycyB0byBtYWtlIGNob2ljZXMgdG8gYWxsb3cgdGVsZXBy ZXNlbmNlIHN5c3RlbXMNCnRvIGludGVyd29yay4gIFRoaXMgbWVtbyBkZXNjcmliZXMgdGhlIG1v c3QgdHlwaWNhbCBhbmQgaW1wb3J0YW50IHVzZQ0KY2FzZXMgZm9yIHNlbmRpbmcgbXVsdGlwbGUg c3RyZWFtcyBpbiBhIHRlbGVwcmVzZW5jZSBjb25mZXJlbmNlLg0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIA0KDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0Lg0KDQoNCg== From magnus.westerlund@ericsson.com Mon Jan 31 04:38: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 1A7AB3A6BFA for ; Mon, 31 Jan 2011 04:38:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.484 X-Spam-Level: X-Spam-Status: No, score=-106.484 tagged_above=-999 required=5 tests=[AWL=0.115, 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 7NLSa6uW5OvU for ; Mon, 31 Jan 2011 04:38:21 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id E305C3A68A7 for ; Mon, 31 Jan 2011 04:38:20 -0800 (PST) X-AuditID: c1b4fb39-b7cfbae000005c8e-51-4d46adfe8784 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 4B.C8.23694.EFDA64D4; Mon, 31 Jan 2011 13:41:34 +0100 (CET) Received: from [147.214.183.170] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.2.234.1; Mon, 31 Jan 2011 13:41:33 +0100 Message-ID: <4D46ADFD.8010506@ericsson.com> Date: Mon, 31 Jan 2011 13:41:33 +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: Peter Musgrave References: <9EEB6465-626A-43B9-A653-A9B67FC01E80@magorcorp.com> In-Reply-To: <9EEB6465-626A-43B9-A653-A9B67FC01E80@magorcorp.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 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: Mon, 31 Jan 2011 12:38:22 -0000 Hi, (AS AVTCore Chair) I want to inject into this discussion a request to be a bit more clear on what people are considering. Because RTP has several multiplexing points and some may even want to go furhter than the existing ones. So can everyone please clarify what they are talking about. Please keep in mind that RTP has certain point of where things are intended to separated. This also affects the possibility to use existing RTP tools. So a primer in RTP terminology: RTP Session: One SSRC space, normally determined based on transport level ports. Each RTP session normally servers one media type and one purpose. Using different media types (audio and video) will creates issues for some tools and SDP based signalling. SSRC, a single media stream source. Multiple SSRC can be used in the same RTP session. RTP payload type, identifies the encoding of the RTP payload. Thus possibly identifying video screen sizes etc. So I will start with asking Peter to clarify the below statement: Peter Musgrave skrev 2011-01-29 08:51: > > I think the notion of a single, multiplexed video stream for a TP endpoint makes a lot of sense in the context of CLUE. I can interpret this as meaning either of: 1. One RTP session, with one SSRC that contains the encoding of multiple different original flows through either transcoding, or a new multiplexing mechanism? 2. One RTP session, with one SSRC per original video stream. So please be clear on what you are discussing and suggesting here. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From stephen.botzko@gmail.com Mon Jan 31 04:49:14 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 A42D73A6C02 for ; Mon, 31 Jan 2011 04:49:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.304 X-Spam-Level: X-Spam-Status: No, score=-3.304 tagged_above=-999 required=5 tests=[AWL=0.294, 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 B3rTh36FP6Ld for ; Mon, 31 Jan 2011 04:49:13 -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 17DA53A6BF0 for ; Mon, 31 Jan 2011 04:49:11 -0800 (PST) Received: by qwi2 with SMTP id 2so5746576qwi.31 for ; Mon, 31 Jan 2011 04:52:25 -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=SKhbXiHqhtomNecgEnW5B58qGdOIcC/w+oQ8b33B7QI=; b=C7cAvxxrnvDcYRHxX3UsPvyc5KJq0EaLCO6kZWB/Ux1ffybS3irrMJhvezOjTh+nsA GneNZNs7FW90lpiYICQxiXrFUPb41CH7m9lCOtHhXBCnyQhcMSjcSLAxicMkypYFAqzh 5z/ddMW+jxy31ztVILtcC13DTL/3POQkYFAvg= 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=gnH6lGGmXfBDhACLWr13hKhHtHPABQD/8v72pnm48yK4MyOl5JoiWMy8f4jiSrfpYv U4nk+DWS2UbQeclkVfGzupT9VLkuf8Doa+zfGrHAJx/0Gn3cD40yiGVcg9k/K1iRDd42 e3DbPjCMFhWTmTNZwE4er7/g2h/K0oC/UvE30= MIME-Version: 1.0 Received: by 10.224.20.4 with SMTP id d4mr6247634qab.345.1296478343394; Mon, 31 Jan 2011 04:52:23 -0800 (PST) Received: by 10.220.128.30 with HTTP; Mon, 31 Jan 2011 04:52:23 -0800 (PST) In-Reply-To: <4D46ADFD.8010506@ericsson.com> References: <9EEB6465-626A-43B9-A653-A9B67FC01E80@magorcorp.com> <4D46ADFD.8010506@ericsson.com> Date: Mon, 31 Jan 2011 07:52:23 -0500 Message-ID: From: Stephen Botzko To: Magnus Westerlund Content-Type: multipart/alternative; boundary=0015175cda2c1df6a0049b23e3f0 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: Mon, 31 Jan 2011 12:49:14 -0000 --0015175cda2c1df6a0049b23e3f0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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 ope= n 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 vide= o 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 < magnus.westerlund@ericsson.com> 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 > --0015175cda2c1df6a0049b23e3f0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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).= =A0 I'd be open to (1) if it did not require transcoding.=A0 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 off= set, in order to simplify lip-sync management with multiple audio and multi= ple video streams.=A0 Not sure about that, but I do see a lot of complexity= in determining the proper delays.

Stephen Botzko


On Mon, Jan 31, 20= 11 at 7:41 AM, Magnus Westerlund <magnus.westerlund@ericsson.com>= 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 endp= oint 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 =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
----------------------------------------------------------------------
_________________________________________= ______
clue mailing list
clue@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/clue

--0015175cda2c1df6a0049b23e3f0-- From eckelcu@cisco.com Mon Jan 31 07: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 977D73A6C36 for ; Mon, 31 Jan 2011 07:46:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.367 X-Spam-Level: X-Spam-Status: No, score=-10.367 tagged_above=-999 required=5 tests=[AWL=0.232, 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 HSkIAfy3XKKl for ; Mon, 31 Jan 2011 07:46:46 -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 965E13A67B4 for ; Mon, 31 Jan 2011 07:46:46 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: As4DALpoRk2rR7H+/2dsb2JhbACWGI5hc6IvmnoChUwEhROKWQ Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-4.cisco.com with ESMTP; 31 Jan 2011 15:50:01 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p0VFo1mr027313; Mon, 31 Jan 2011 15:50:01 GMT Received: from xmb-sjc-234.amer.cisco.com ([128.107.191.111]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 31 Jan 2011 07:50:01 -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, 31 Jan 2011 07:49:59 -0800 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] Multiple Streams - RTP muxing? Thread-Index: AcvBRdF7z9AtjXYmSJKqHPHgbzDXrwAF36WA References: <9EEB6465-626A-43B9-A653-A9B67FC01E80@magorcorp.com><4D46ADFD.8010506@ericsson.com> From: "Charles Eckel (eckelcu)" To: "Stephen Botzko" , "Magnus Westerlund" X-OriginalArrivalTime: 31 Jan 2011 15:50:01.0290 (UTC) FILETIME=[8503DAA0:01CBC15E] 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: Mon, 31 Jan 2011 15:46:47 -0000 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? >=20 > 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? >=20 > 2. One RTP session, with one SSRC per original video stream. > >>> >=20 > 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. >=20 > 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. >=20 > Stephen Botzko >=20 >=20 >=20 > On Mon, Jan 31, 2011 at 7:41 AM, Magnus Westerlund = wrote: >=20 >=20 > Hi, >=20 > (AS AVTCore Chair) >=20 > 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. >=20 > 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. >=20 > So a primer in RTP terminology: >=20 > 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. >=20 > SSRC, a single media stream source. Multiple SSRC can be used in the > same RTP session. >=20 > RTP payload type, identifies the encoding of the RTP payload. Thus > possibly identifying video screen sizes etc. >=20 > So I will start with asking Peter to clarify the below statement: >=20 > Peter Musgrave skrev 2011-01-29 08:51: >=20 > > > > I think the notion of a single, multiplexed video 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 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 suggesting here. >=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 > = ---------------------------------------------------------------------- >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue >=20 >=20 From christer.holmberg@ericsson.com Mon Jan 31 08:12:08 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 4423A3A6C07 for ; Mon, 31 Jan 2011 08:12:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.469 X-Spam-Level: X-Spam-Status: No, score=-6.469 tagged_above=-999 required=5 tests=[AWL=0.130, 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 WZKvGbirkXYz for ; Mon, 31 Jan 2011 08:12:07 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 94D3E3A6AAF for ; Mon, 31 Jan 2011 08:12:06 -0800 (PST) X-AuditID: c1b4fb39-b7cfbae000005c8e-4f-4d46e018be74 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 52.86.23694.810E64D4; Mon, 31 Jan 2011 17:15:20 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.59]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Mon, 31 Jan 2011 17:15:20 +0100 From: Christer Holmberg To: "'Charles Eckel (eckelcu)'" , Stephen Botzko , Magnus Westerlund Date: Mon, 31 Jan 2011 17:15:19 +0100 Thread-Topic: [clue] Multiple Streams - RTP muxing? Thread-Index: AcvBRdF7z9AtjXYmSJKqHPHgbzDXrwAF36WAAAEWNyA= Message-ID: <7F2072F1E0DE894DA4B517B93C6A05851944155A25@ESESSCMS0356.eemea.ericsson.se> 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 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: Mon, 31 Jan 2011 16:12:08 -0000 Hi, We can discuss the pros and cons of RTP muxing etc, but before making any i= mplementation decissions we first need to decide upon the use-cases and req= uirements. Regards, Christer =20 -----Original Message----- From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Cha= rles Eckel (eckelcu) Sent: 31. tammikuuta 2011 17: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 programm= atic as well. I am hoping those more familiar with the complexities and limitations of RT= P stream processing can chime in. Will we have no choice but to break it in= to multiple RTP sessions? Thanks, Charles > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf=20 > 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 encoding of=20 > multiple different original flows through either transcoding, or a new=20 > 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 video). I'd=20 > be open to (1) if it did not require transcoding. However, I am not conv= inced a totally new mechanism is needed. >=20 > Though it hasn't come up yet, I was also wondering about having all=20 > video and audio streams from the same CLUE endpoint use the same clock=20 > offset, in order to simplify lip-sync management with multiple audio=20 > and multiple video streams. Not sure about that, but I do see a lot of c= omplexity in determining the proper delays. >=20 > Stephen Botzko >=20 >=20 >=20 > On Mon, Jan 31, 2011 at 7:41 AM, Magnus Westerlund wrote: >=20 >=20 > Hi, >=20 > (AS AVTCore Chair) >=20 > 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. >=20 > 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. >=20 > So a primer in RTP terminology: >=20 > 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. >=20 > SSRC, a single media stream source. Multiple SSRC can be used in the > same RTP session. >=20 > RTP payload type, identifies the encoding of the RTP payload. Thus > possibly identifying video screen sizes etc. >=20 > So I will start with asking Peter to clarify the below statement: >=20 > Peter Musgrave skrev 2011-01-29 08:51: >=20 > > > > I think the notion of a single, multiplexed video stream for a TP=20 > 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 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 suggesting here. >=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 > =09 > ---------------------------------------------------------------------- >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue >=20 >=20 _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue From aravind.sethuraman@teliris.com Mon Jan 31 11:00: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 7FCF63A6C40 for ; Mon, 31 Jan 2011 11:00:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.432 X-Spam-Level: X-Spam-Status: No, score=-3.432 tagged_above=-999 required=5 tests=[AWL=0.166, 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 c3jClFYb5umv for ; Mon, 31 Jan 2011 11:00:41 -0800 (PST) Received: from imta-38.everyone.net (imta-35.everyone.net [216.200.145.35]) by core3.amsl.com (Postfix) with ESMTP id 2C6473A6B32 for ; Mon, 31 Jan 2011 11:00:41 -0800 (PST) Received: from pps.filterd (omta001 [127.0.0.1]) by imta-38.everyone.net (8.14.4/8.14.4) with SMTP id p0VJ2sJO028468; Mon, 31 Jan 2011 11:03:52 -0800 Received: from dm0207.mta.everyone.net (sj1-slb03-gw2.sj2.proofpoint.com [172.16.1.96]) by imta-38.everyone.net with ESMTP id u62r2g4qs-1; Mon, 31 Jan 2011 11:03:52 -0800 X-Eon-Dm: dm0207 Received: by dm0207.mta.everyone.net (EON-AUTHRELAY2 - 7aa4370c) id dm0207.4d4436fe.403467; Mon, 31 Jan 2011 11:03:44 -0800 X-Eon-Sig: AQLO6zJNRweQ5sm1CgIAAAAD,969f73faec3330b30bc50933e4d55e2c Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-1-365841682 From: aravind sethuraman In-Reply-To: Date: Tue, 1 Feb 2011 00:33:41 +0530 Message-Id: References: <9EEB6465-626A-43B9-A653-A9B67FC01E80@magorcorp.com> <4D46ADFD.8010506@ericsson.com> To: Stephen Botzko X-Mailer: Apple Mail (2.1082) X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1012030000 definitions=main-1101310122 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: Mon, 31 Jan 2011 19:00:42 -0000 --Apple-Mail-1-365841682 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 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. One problem i have with not going with multiple m lines in SDP is how do = we define at session set up the following 1. Interop with systems with no CLUE 2. interop with assymetric system - for instance, i am a h264 svc 4 = screen system and i invite a system capable of 3 screens h264 avc but = for some reason (either bandwidth restrictions etc), this system offers = back a single screen on uplink but it can still receive the 4 screens = which can be rendered on the 3 system's single screen. How can we = represent this via pure RTP muxing and no multiple m lines? thanks aravind On Jan 31, 2011, at 6:22 PM, Stephen Botzko wrote: > 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? >=20 > 2. One RTP session, with one SSRC per original video stream. > >>> >=20 > 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. >=20 > 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. >=20 > Stephen Botzko >=20 >=20 > On Mon, Jan 31, 2011 at 7:41 AM, Magnus Westerlund = wrote: > Hi, >=20 > (AS AVTCore Chair) >=20 > 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. >=20 > 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. >=20 > So a primer in RTP terminology: >=20 > 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. >=20 > SSRC, a single media stream source. Multiple SSRC can be used in the > same RTP session. >=20 > RTP payload type, identifies the encoding of the RTP payload. Thus > possibly identifying video screen sizes etc. >=20 > So I will start with asking Peter to clarify the below statement: >=20 > 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. >=20 > I can interpret this as meaning either of: >=20 > 1. One RTP session, with one SSRC that contains the 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 suggesting here. >=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 > ---------------------------------------------------------------------- > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue Aravind Sethuraman Software Architect Teliris, Inc. | 55 Broadway, 14th Floor, New York, NY 10006 | C = +1.917.355.0119 | O +1.212.490.1065 x1408 | F +1.212.269.2869 | AIM = aravindsraman --Apple-Mail-1-365841682 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 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.

One problem i have with not = going with multiple m lines in SDP is how do we define at session set up = the following
1. Interop with systems with no = CLUE
2. interop with assymetric system - for instance, i am a = h264 svc 4 screen system and i invite a system capable of 3 screens h264 = avc but for some reason (either bandwidth restrictions etc), this system = offers back a single screen on uplink but it can still receive the 4 = screens which can be rendered on the 3 system's single screen. How can = we represent this via pure RTP muxing and no multiple m = lines?

thanks
aravind

On Jan 31, 2011, at 6:22 PM, Stephen Botzko wrote:

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 <magnus.westerlund@ericsson.= com> 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/ma= ilman/listinfo/clue

Aravind = Sethuraman
Software Architect
Teliris, Inc. | 55 Broadway, 14th = Floor, New York, NY 10006 | C +1.917.355.0119 | O = +1.212.490.1065 x1408 | F +1.212.269.2869 | AIM = aravindsraman

= --Apple-Mail-1-365841682-- From stephen.botzko@gmail.com Mon Jan 31 11:43:32 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 F3E663A6C3F for ; Mon, 31 Jan 2011 11:43:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.322 X-Spam-Level: X-Spam-Status: No, score=-3.322 tagged_above=-999 required=5 tests=[AWL=0.276, 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 6RHhvSnLPyHF for ; Mon, 31 Jan 2011 11:43:30 -0800 (PST) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id 0E1643A6C36 for ; Mon, 31 Jan 2011 11:43:29 -0800 (PST) Received: by qyj19 with SMTP id 19so6136490qyj.10 for ; Mon, 31 Jan 2011 11:46:44 -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=S6Ck6COFTDOfvDIKoI47stcyRKC6fsrSBrmAQWIHR74=; b=Brfqs8jZts1VLAGXWlmzp2dgYDzqz2XlhHjcyt6/nW2Wc8wgeeWqbo+BkKyp+LZhRX LY6MKarsMyBvaL40awlUz6FNfBt0M1zE2GCkrZ2mNyMmDFX3xfGdiLFMl4yJsFva6DEf 0JyICtQMtWQiPcKIB8Qr475E2nqhOoEpcvWfw= 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=PFIjgGlpKppkSzmmKhz1C+jW/a1Hsn87acd4OeANYIrbYnKd+jI+4E6Vhk08By1z52 IqOCZNoqoYqMh9g8MXFHRdpReUdgL+6DaKNc7eky4FWUe8WNRjvmY0O4lNzgdGwyn0q8 WdrlXQvuK6IddsQ43bp1EYAx2aikKXtQl2Au0= MIME-Version: 1.0 Received: by 10.229.238.82 with SMTP id kr18mr6259989qcb.98.1296503163054; Mon, 31 Jan 2011 11:46:03 -0800 (PST) Received: by 10.220.128.30 with HTTP; Mon, 31 Jan 2011 11:46:02 -0800 (PST) In-Reply-To: References: <9EEB6465-626A-43B9-A653-A9B67FC01E80@magorcorp.com> <4D46ADFD.8010506@ericsson.com> Date: Mon, 31 Jan 2011 14:46:02 -0500 Message-ID: From: Stephen Botzko To: aravind sethuraman Content-Type: multipart/alternative; boundary=0016e64b03b67bec7a049b29aa85 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: Mon, 31 Jan 2011 19:43:32 -0000 --0016e64b03b67bec7a049b29aa85 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I am not sure what you mean by "pure RTP muxing". The semantics of multiple streams is what CLUE was formed to define. From the charter: "The working group will define the semantics, syntax, and transport mechanism for communicating the necessary information." I imagine this will involve new m lines, but is not limited to that. Many of the use cases require quite fluid behavior, so it is possible that setting up a multiplexed RTP stream (with an m line!) whose stream content is managed by a different mechanism than offer/answer is a better way to go. We will see as the work progresses. Certainly interoperability with existing videoconferencing systems requires m-lines that are compatible with what those systems do today. Stephen Botzko On Mon, Jan 31, 2011 at 2:03 PM, aravind sethuraman < aravind.sethuraman@teliris.com> wrote: > 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. > > One problem i have with not going with multiple m lines in SDP is how do = we > define at session set up the following > 1. Interop with systems with no CLUE > 2. interop with assymetric system - for instance, i am a h264 svc 4 scree= n > system and i invite a system capable of 3 screens h264 avc but for some > reason (either bandwidth restrictions etc), this system offers back a sin= gle > screen on uplink but it can still receive the 4 screens which can be > rendered on the 3 system's single screen. How can we represent this via p= ure > RTP muxing and no multiple m lines? > > thanks > aravind > > On Jan 31, 2011, at 6:22 PM, Stephen Botzko wrote: > > 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 convinc= ed > 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 vi= deo > 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 < > magnus.westerlund@ericsson.com> 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 > > > Aravind Sethuraman > Software Architect > Teliris, Inc. | 55 Broadway, 14th Floor, New York, NY 10006 | C > +1.917.355.0119 | O +1.212.490.1065 x1408 | F +1.212.269.2869 | AIM > aravindsraman > > > --0016e64b03b67bec7a049b29aa85 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I am not sure what you mean by "pure RTP muxing".

The sem= antics of multiple streams is what CLUE was formed to define. From the char= ter: "The working group will define the semantics, syntax, and transpo= rt mechanism for communicating the necessary information."=A0

I imagine this will involve new m lines, but is not limited to that.=A0= Many of the use cases require quite fluid behavior, so it is possible that= setting up a multiplexed RTP stream (with an m line!) whose stream content= is managed by a different mechanism than offer/answer is a better way to g= o.=A0 We will see as the work progresses.

Certainly interoperability with existing videoconferencing systems requ= ires m-lines that are compatible with what those systems do today.

S= tephen Botzko



On Mon, Jan 31, 201= 1 at 2:03 PM, aravind sethuraman <aravind.sethuraman@teliris.com>= wrote:
Hi all,
if we chose a single RTP session for ALL v= ideo and AUDIO, how will we signal which SSRC conforms to which screen etc?= Not via RTCP like TIP does.

One problem i have with not going with multiple m lines= in SDP is how do we define at session set up the following
1. In= terop with systems with no CLUE
2. interop with assymetric system= - for instance, i am a h264 svc 4 screen system and i invite a system capa= ble of 3 screens h264 avc but for some reason (either bandwidth restriction= s etc), this system offers back a single screen on uplink but it can still = receive the 4 screens which can be rendered on the 3 system's single sc= reen. How can we represent this via pure RTP muxing and no multiple m lines= ?

thanks
aravind

On Jan 31, 2011, at 6:22 PM, Stephen Botzko wro= te:

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).= =A0 I'd be open to (1) if it did not require transcoding.=A0 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 off= set, in order to simplify lip-sync management with multiple audio and multi= ple video streams.=A0 Not sure about that, but I do see a lot of complexity= in determining the proper delays.

Stephen Botzko


On Mon, Jan 31, 20= 11 at 7:41 AM, Magnus Westerlund <magnus.westerlund@ericsson.= com> 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 endp= oint 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 =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
----------------------------------------------------------------------
_______________________________________________
clue mailing list
clue@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/clue

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

Aravind Sethuraman
Software Architect
Teliris, Inc. | 55 Broadway, 14th Floor, New York,=A0= NY 10006 | C +1.917.355.0119 | O +1.212.490.1065=A0x1408 | F +1.212.269.286= 9 | AIM aravindsraman


--0016e64b03b67bec7a049b29aa85-- From aravind.sethuraman@teliris.com Mon Jan 31 11:50:17 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 347AF3A6C70 for ; Mon, 31 Jan 2011 11:50:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.473 X-Spam-Level: X-Spam-Status: No, score=-3.473 tagged_above=-999 required=5 tests=[AWL=0.125, 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 TdXKd4umRt+V for ; Mon, 31 Jan 2011 11:50:15 -0800 (PST) Received: from imta-38.everyone.net (imta-35.everyone.net [216.200.145.35]) by core3.amsl.com (Postfix) with ESMTP id 9FBE83A6C71 for ; Mon, 31 Jan 2011 11:50:15 -0800 (PST) Received: from pps.filterd (omta001 [127.0.0.1]) by imta-38.everyone.net (8.14.4/8.14.4) with SMTP id p0VJrMK4002106; Mon, 31 Jan 2011 11:53:26 -0800 Received: from dm0206.mta.everyone.net (sj1-slb03-gw2.sj2.proofpoint.com [172.16.1.96]) by imta-38.everyone.net with ESMTP id u63fs846w-1; Mon, 31 Jan 2011 11:53:26 -0800 X-Eon-Dm: dm0206 Received: by dm0206.mta.everyone.net (EON-AUTHRELAY2 - 7aa4370c) id dm0206.4d443700.41652b; Mon, 31 Jan 2011 11:53:12 -0800 X-Eon-Sig: AQLO6zJNRxMoWAN3fgIAAAAD,196e8e75d647a715cdb763d54ad7217f Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-4-368808866 From: aravind sethuraman In-Reply-To: Date: Tue, 1 Feb 2011 01:23:08 +0530 Message-Id: <85336645-7BDA-470B-9E16-0B6340714838@teliris.com> References: <9EEB6465-626A-43B9-A653-A9B67FC01E80@magorcorp.com> <4D46ADFD.8010506@ericsson.com> To: Stephen Botzko X-Mailer: Apple Mail (2.1082) X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1012030000 definitions=main-1101310132 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: Mon, 31 Jan 2011 19:50:17 -0000 --Apple-Mail-4-368808866 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 by "pure RTP muxing", i intended to mean a single port of receipt and = transfer of the multiplexed RTP streams . On Feb 1, 2011, at 1:16 AM, Stephen Botzko wrote: > I am not sure what you mean by "pure RTP muxing".=20 >=20 > The semantics of multiple streams is what CLUE was formed to define. = =46rom the charter: "The working group will define the semantics, = syntax, and transport mechanism for communicating the necessary = information." =20 >=20 > I imagine this will involve new m lines, but is not limited to that. = Many of the use cases require quite fluid behavior, so it is possible = that setting up a multiplexed RTP stream (with an m line!) whose stream = content is managed by a different mechanism than offer/answer is a = better way to go. We will see as the work progresses. >=20 > Certainly interoperability with existing videoconferencing systems = requires m-lines that are compatible with what those systems do today. >=20 > Stephen Botzko >=20 >=20 >=20 > On Mon, Jan 31, 2011 at 2:03 PM, aravind sethuraman = wrote: > 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. >=20 > One problem i have with not going with multiple m lines in SDP is how = do we define at session set up the following > 1. Interop with systems with no CLUE > 2. interop with assymetric system - for instance, i am a h264 svc 4 = screen system and i invite a system capable of 3 screens h264 avc but = for some reason (either bandwidth restrictions etc), this system offers = back a single screen on uplink but it can still receive the 4 screens = which can be rendered on the 3 system's single screen. How can we = represent this via pure RTP muxing and no multiple m lines? >=20 > thanks > aravind >=20 > On Jan 31, 2011, at 6:22 PM, Stephen Botzko wrote: >=20 >> 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? >>=20 >> 2. One RTP session, with one SSRC per original video stream. >> >>> >>=20 >> 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. >>=20 >> 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. >>=20 >> Stephen Botzko >>=20 >>=20 >> On Mon, Jan 31, 2011 at 7:41 AM, Magnus Westerlund = wrote: >> Hi, >>=20 >> (AS AVTCore Chair) >>=20 >> 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. >>=20 >> 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. >>=20 >> So a primer in RTP terminology: >>=20 >> 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. >>=20 >> SSRC, a single media stream source. Multiple SSRC can be used in the >> same RTP session. >>=20 >> RTP payload type, identifies the encoding of the RTP payload. Thus >> possibly identifying video screen sizes etc. >>=20 >> So I will start with asking Peter to clarify the below statement: >>=20 >> 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. >>=20 >> I can interpret this as meaning either of: >>=20 >> 1. One RTP session, with one SSRC that contains the 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 suggesting here. >>=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 >> = ---------------------------------------------------------------------- >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >>=20 >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >=20 > Aravind Sethuraman > Software Architect > Teliris, Inc. | 55 Broadway, 14th Floor, New York, NY 10006 | C = +1.917.355.0119 | O +1.212.490.1065 x1408 | F +1.212.269.2869 | AIM = aravindsraman >=20 >=20 >=20 Aravind Sethuraman Software Architect Teliris, Inc. | 55 Broadway, 14th Floor, New York, NY 10006 | C = +1.917.355.0119 | O +1.212.490.1065 x1408 | F +1.212.269.2869 | AIM = aravindsraman --Apple-Mail-4-368808866 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 by = "pure RTP muxing", i intended to mean a single port of receipt and = transfer of the multiplexed RTP streams .

On Feb 1, = 2011, at 1:16 AM, Stephen Botzko wrote:

I am not = sure what you mean by "pure RTP muxing".

The semantics of = multiple streams is what CLUE was formed to define. =46rom the charter: = "The working group will define the semantics, syntax, and transport = mechanism for communicating the necessary information." 

I imagine this will involve new m lines, but is not limited to = that.  Many of the use cases require quite fluid behavior, so it is = possible that setting up a multiplexed RTP stream (with an m line!) = whose stream content is managed by a different mechanism than = offer/answer is a better way to go.  We will see as the work = progresses.

Certainly interoperability with existing videoconferencing systems = requires m-lines that are compatible with what those systems do = today.

Stephen Botzko



On = Mon, Jan 31, 2011 at 2:03 PM, aravind sethuraman <aravind.sethuraman@teliris.= com> wrote:
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.

One problem i have with not going with multiple m = lines in SDP is how do we define at session set up the = following
1. Interop with systems with no CLUE
2. = interop with assymetric system - for instance, i am a h264 svc 4 screen = system and i invite a system capable of 3 screens h264 avc but for some = reason (either bandwidth restrictions etc), this system offers back a = single screen on uplink but it can still receive the 4 screens which can = be rendered on the 3 system's single screen. How can we represent this = via pure RTP muxing and no multiple m lines?
=

thanks
aravind

On Jan 31, 2011, at 6:22 PM, Stephen Botzko = wrote:

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 <magnus.westerlund@ericsson.com> = 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

Aravind Sethuraman
Software Architect
Teliris, Inc. | 55 Broadway, 14th Floor, New = York, NY 10006 | C +1.917.355.0119 | O +1.212.490.1065 x1408 | = F +1.212.269.2869 | AIM aravindsraman



Aravind = Sethuraman
Software Architect
Teliris, Inc. | 55 Broadway, 14th = Floor, New York, NY 10006 | C +1.917.355.0119 | O = +1.212.490.1065 x1408 | F +1.212.269.2869 | AIM = aravindsraman

= --Apple-Mail-4-368808866-- From jonathan@vidyo.com Mon Jan 31 13:12:21 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 0DF8F3A6864 for ; Mon, 31 Jan 2011 13:12:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599] 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 ZDzzJZbDcF0u for ; Mon, 31 Jan 2011 13:12:03 -0800 (PST) Received: from mx1.myoutlookonline.com (mx1.myoutlookonline.com [64.95.72.238]) by core3.amsl.com (Postfix) with ESMTP id 513AE3A6AEB for ; Mon, 31 Jan 2011 13:12:02 -0800 (PST) Received: from st021.mx1.myoutlookonline.com (localhost [127.0.0.1]) by mx1.myoutlookonline.com (Postfix) with ESMTP id B978A553BC3; Mon, 31 Jan 2011 16:15:16 -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 AB1A5553992; Mon, 31 Jan 2011 16:15:15 -0500 (EST) Received: from BH016.mail.lan ([10.110.21.116]) by mx1.myoutlookonline.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 31 Jan 2011 16:14:50 -0500 Received: from HUB016.mail.lan ([10.110.17.16]) by BH016.mail.lan with Microsoft SMTPSVC(6.0.3790.3959); Mon, 31 Jan 2011 16:15:03 -0500 Received: from BE235.mail.lan ([10.110.32.235]) by HUB016.mail.lan ([10.110.17.16]) with mapi; Mon, 31 Jan 2011 16:14:46 -0500 From: Jonathan Lennox To: "Charles Eckel (eckelcu)" Date: Mon, 31 Jan 2011 16:15:10 -0500 Thread-Topic: [clue] Multiple Streams - RTP muxing? Thread-Index: AcvBi+xcjJaQia7OQ5eyD6mN8TV2cg== Message-ID: <7A6BA6C5-F192-43CB-82F1-10DEB1CC7C3E@vidyo.com> 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 X-OriginalArrivalTime: 31 Jan 2011 21:15:03.0944 (UTC) FILETIME=[ED80B080:01CBC18B] 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: Mon, 31 Jan 2011 21:12:21 -0000 Our existing system does SSRC multiplexing for multipoint video conferencin= g (allowing client-side rendering of multiple video streams without requiri= ng a transcoding middlebox). It works quite nicely -- we can easily have s= essions with hundreds of sources, each with a unique SSRC. (Not all being = sent at once, of course, for bandwidth reasons, but potentially with dozens= of them being sent at a time, switching dynamically.) As mentioned previously, this simplifies NAT/firewall traversal substantial= ly. 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. Your RTP stack has to be implemented properly, of course -- e.g., using O(1= ) operations like hash tables to look up SSRC values, rather than O(n) oper= ations like linked lists. But in general, the cost of SSRC demux is pretty= trivial compared to everything else that needs to be done in order to succ= essfully decode and render video. I strongly encourage this behavior for telepresence as well. On Jan 31, 2011, at 10:49 AM, Charles Eckel (eckelcu) wrote: > I was thinking (2) as well; however, one concern I have is scalability. A= s the number of screens increases from 3 or so to say 10 or 100, does the s= et of pros and cons change. I would hate to have 100 m-lines, but 100 strea= ms each with its own SSRC multiplexed in a single RTP session may be progra= mmatic 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? >=20 > Thanks, > Charles >=20 >> -----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? >>=20 >> Hi >>>>>=20 >> 1. One RTP session, with one SSRC that contains the 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 >>=20 >> 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 mechanis= m is needed. >>=20 >> Though it hasn't come up yet, I was also wondering about having all vide= o and audio streams from the >> same CLUE endpoint use the same clock offset, in order to simplify lip-s= ync management with multiple >> audio and multiple video streams. Not sure about that, but I do see a l= ot of complexity in >> determining the proper delays. >>=20 >> Stephen Botzko >>=20 >>=20 >>=20 >> On Mon, Jan 31, 2011 at 7:41 AM, Magnus Westerlund wrote: >>=20 >>=20 >> Hi, >>=20 >> (AS AVTCore Chair) >>=20 >> 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. >>=20 >> Please keep in mind that RTP has certain point of where things are >> intended to separated. This also affects the possibility to use existin= g >> RTP tools. >>=20 >> So a primer in RTP terminology: >>=20 >> 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. >>=20 >> SSRC, a single media stream source. Multiple SSRC can be used in the >> same RTP session. >>=20 >> RTP payload type, identifies the encoding of the RTP payload. Thus >> possibly identifying video screen sizes etc. >>=20 >> So I will start with asking Peter to clarify the below statement: >>=20 >> Peter Musgrave skrev 2011-01-29 08:51: >>=20 >> > >> > I think the notion of a single, multiplexed video stream for a TP end= point 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 encoding of multipl= e >> 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 suggesting here. >>=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 >> ---------------------------------------------------------------------- >>=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 >=20 -- Jonathan Lennox jonathan@vidyo.com From peter.musgrave@magorcorp.com Mon Jan 31 19:49:28 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 C1FB93A67D3 for ; Mon, 31 Jan 2011 19:49:28 -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.001, 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 DUCXaT99QIAy for ; Mon, 31 Jan 2011 19:49:28 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id A5B973A69E2 for ; Mon, 31 Jan 2011 19:49:27 -0800 (PST) Received: by wwa36 with SMTP id 36so7065554wwa.13 for ; Mon, 31 Jan 2011 19:52:42 -0800 (PST) Received: by 10.216.164.69 with SMTP id b47mr6467797wel.79.1296532362881; Mon, 31 Jan 2011 19:52:42 -0800 (PST) Received: from [10.116.0.176] (62-50-198-228.client.stsn.net [62.50.198.228]) by mx.google.com with ESMTPS id r57sm1824585wes.25.2011.01.31.19.52.40 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 31 Jan 2011 19:52:41 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Peter Musgrave In-Reply-To: <7A6BA6C5-F192-43CB-82F1-10DEB1CC7C3E@vidyo.com> Date: Tue, 1 Feb 2011 04:52:38 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <5EAED581-D895-435A-84B5-997A31C0868D@magorcorp.com> References: <9EEB6465-626A-43B9-A653-A9B67FC01E80@magorcorp.com><4D46ADFD.8010506@ericsson.com> <7A6BA6C5-F192-43CB-82F1-10DEB1CC7C3E@vidyo.com> To: Jonathan Lennox 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: Tue, 01 Feb 2011 03:49:28 -0000 I find the point you make about the dynamic SSRC content and source = switching very compelling.=20 I also find "real code" doing this at the level of hundreds a good proof = point. Peter Musgrave On 2011-01-31, at 10:15 PM, Jonathan Lennox wrote: > Our existing system does SSRC multiplexing for multipoint video = conferencing (allowing client-side rendering of multiple video streams = without requiring a transcoding middlebox). It works quite nicely -- we = can easily have sessions with hundreds of sources, each with a unique = SSRC. (Not all being sent at once, of course, for bandwidth reasons, = but potentially with dozens of them being sent at a time, switching = dynamically.)