From stephen.botzko@gmail.com Tue May 1 00:11:28 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05D5D21F864A for ; Tue, 1 May 2012 00:11:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.281 X-Spam-Level: X-Spam-Status: No, score=-3.281 tagged_above=-999 required=5 tests=[AWL=0.317, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BkNH5YeU1xKW for ; Tue, 1 May 2012 00:11:26 -0700 (PDT) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by ietfa.amsl.com (Postfix) with ESMTP id 9448F21F8649 for ; Tue, 1 May 2012 00:11:26 -0700 (PDT) Received: by dady13 with SMTP id y13so6730921dad.27 for ; Tue, 01 May 2012 00:11:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=H1UVdqAYVkhVMCOb+utUkJl9Ba1U9CfNQyNKNMVWFZM=; b=VfGJVPOYR+jwjiSdhdtnAqUi68b0veePlovMfy3ME1PS6p5DtLBOUJx2bcahwfIwMD oTDPoGnNzUg8mw7Eb6zck8wHX22t1FFcaLXIl4Qe9EOW4t4rF1hkJJ1XC6Kp8l8Zku2p 3RtiSErtxT/dupIKPFLVYm5BsorK21Txm23Tsiyl3mD2dvgpyf6SRLLz2UrsUTegkFJR 72NnZOWkASsu9BGzTsMMRCqFQ2sXbnZmU69oVH+DhXcgc8kQrRRN8vP/ejPC6q3PRiSZ dTv+ubKllixMR/q8SUHCUu1/h3i6Hcnmte/yr8vF4HL8n81lpasq5WGXyldmtyznzYop 2zFQ== MIME-Version: 1.0 Received: by 10.68.136.68 with SMTP id py4mr871457pbb.122.1335856286168; Tue, 01 May 2012 00:11:26 -0700 (PDT) Received: by 10.68.239.228 with HTTP; Tue, 1 May 2012 00:11:25 -0700 (PDT) In-Reply-To: <4F9EC454.3060605@alum.mit.edu> References: <4F997E6B.7070501@alum.mit.edu> <4F9B0D81.4040608@alum.mit.edu> <4F9EC454.3060605@alum.mit.edu> Date: Tue, 1 May 2012 03:11:25 -0400 Message-ID: From: Stephen Botzko To: Paul Kyzivat Content-Type: multipart/alternative; boundary=047d7b15a8c36877a304bef4476b Cc: CLUE Subject: Re: [clue] ways of managing presentations in telepresence sessions X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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 May 2012 07:11:28 -0000 --047d7b15a8c36877a304bef4476b Content-Type: text/plain; charset=ISO-8859-1 On Mon, Apr 30, 2012 at 12:56 PM, Paul Kyzivat wrote: > On 4/28/12 1:18 PM, Stephen Botzko wrote: > > [sb] As I mentioned above, the existing solutions usually include a >> screen-scrape application, so you don't have to use a video cable. This >> is essentially the same as using Webex for presenting (but not remote >> control). >> > > How are these solutions connected? Does the captured application data go > to the local room controller, or to an MCU in the middle of the TP session? > Or something else? > [sb] They are normally connected to the local room telepresence system. > Again, the people in the local room also need to see the presentation, so > this is the most direct and also is the most bandwidth efficient approach. > Another aspect is that the rooms can and are used purely locally (with no > remote systems at all), and presentations also need to work in that > situation. BTW I think adding requirements for support of multiple > endpoints in the same room is an unwise path - this is not SPLICES, and we > have enough to do already. I agree with folks who are saying it is out of > scope[/sb] > > > Also, even though Webex allows remote control, in my >> experience that feature is not used as much as simple presenting. I am >> not saying it has no value, just that the most common case I see is a >> simple presentation. >> > > That is my experience as well. I wasn't thinking about the > multi-user-control aspect. > > > Supporting the video cable still has value, especially if you have guest >> presenter who does not have access to your local network. Most of those >> presenters are expecting to use a projector, so they have the cables >> with them. >> > > Surely. In this case, I presume the cable connects to the local room > controller. If there are multiple cable connectors (e.g. one at each seat) > do they show up as multiple presentation streams? Or is there some sort of > switch and floor control? If so, how does one manage the floor control? > [sb] Today there is one presenter at a time. With multiple cables, there > is usually a button at each spot, and if you press it you become the > presenter (most recent request wins is the policy). Normal social > courtesies handle conflict, so there is no real need for formal floor > control. This happens even in ordinary webex conferences - if someone > grabs the ball when they shouldn't have it, people say something and it > gets resolved. Similarly, if someone needs the ball. More precisely, the > presenting video system holds the token for the room. With H.239, the MCU > (if there is one) grants it, using whatever policy it wants, and can revoke > it at any time. In point-to-point calls, the far end SHALL grant it upon > request, so in that case the turn-taking policy is mandated in the > standard. Multiple presenters in the same room is up to the local room > policy - there is no standard, and in my opinion none is needed. The token > remains owned by the local video system, it is allowed to present whatever > local source it wishes. [/sb] > My answer on application sharing falling "out of favor" related >> specifically to vendor support for standards-based application sharing >> (T.120 in particular) - which I thought was responsive to your original >> question. Perhaps I misunderstood it. Anyway there were several >> reasons [and perhaps various viewpoints] on why T.120 was dropped, >> though I think it is probably not a useful discussion for this list. I >> know of no other standards-based protocol for application sharing. >> > > I wasn't assuming there was, other than a pure video (and maybe audio) > stream interface. There are other fora for that sort of thing, but its my > impression that this is largely a world of proprietary and defacto > standards. > > > BTW, it is relatively common for web screen sharing to co-exist with the >> videoconferencing presentation methods. For instance, you can have a >> stand-alone webex conference, with someone sharing their laptop screen >> for the video participants.[/sb] >> > > I have done this. But it was cumbersome. IIRC, getting the sharing to be > visible in the room I was in required using a video cable in addition to > using webex sharing. [sb]With our equipment you could use the cable if you wished, but it would not be required. Though generally speaking, people are used to using projectors for presenting. Video systems are providing identical interfaces, so they work the way people expect. For instance, in IETF interim meetings the Webex screen is always presented locally, frequently using a cable. The chairs may find that cumbersome, but they certainly come into the meeting expecting to do it anyway.[\sb] > > > Of course that is still somewhat cumbersome, but presumably it will >> be improved over time. Its the UI for driving it that is cumbersome, >> not the output. >> >> A key difference is that if the computer output is via video cable >> into the local room controller, then that is probably responsible >> for displaying it locally on a display in the room as well as >> sending it to the remote end. If the users connect their computers >> directly to the MCU, then the capture will come to the room just >> like anything else from the MCU. >> >> [sb]The standard model for videoconferencing presentations is a >> token-controlled transmission. If you don't have the token, you are >> receiving. The local equipment is always responsible for display. >> Looping the presentation back through the MCU back to the originating >> site wastes bandwidth. >> >> I don't know if web conferencing solutions do this differently or not. >> I've always assumed that when I grab the webex "ball" I stop receiving >> desktop images. Certainly there is no reason for the server to send >> them back to me.[/sb] >> > > Thanks, > Paul > --047d7b15a8c36877a304bef4476b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Mon, Apr 30, 2012 at 12:56 PM, Paul K= yzivat <pkyzivat@alum.mit.edu> wrote:
On 4/28/12 1:18 PM, Stephen Botzko wrote:

[sb] As I mentioned above, the existing solutions usually include a
screen-scrape application, so you don't have to use a video cable. This=
is essentially the same as using Webex for presenting (but not remote
control).

How are these solutions connected? Does the captured application data go to= the local room controller, or to an MCU in the middle of the TP session? O= r something else?
[sb] They are normally connected to the local room te= lepresence system.=A0 Again, the people in the local room also need to see = the presentation, so this is the most direct and also is the most bandwidth= efficient approach.=A0 Another aspect is that the rooms can and are used p= urely locally (with no remote systems at all), and presentations also need = to work in that situation.=A0 BTW I think adding requirements for support o= f multiple endpoints in the same room is an unwise path -=A0 this is not SP= LICES, and we have enough to do already.=A0 I agree with folks who are sayi= ng it is out of scope[/sb]

<= div class=3D"im">
Also, even though Webex allows remote control, in my
experience that feature is not used as much as simple presenting. =A0I am not saying it has no value, just that the most common case I see is a
simple presentation.

That is my experience as well. I wasn't thinking about the multi-user-c= ontrol aspect.


Supporting the video cable still has value, especially if you have guest presenter who does not have access to your local network. =A0Most of those<= br> presenters are expecting to use a projector, so they have the cables
with them.

Surely. In this case, I presume the cable connects to the local room contro= ller. If there are multiple cable connectors (e.g. one at each seat) do the= y show up as multiple presentation streams? Or is there some sort of switch= and floor control? If so, how does one manage the floor control?
[sb] Today there is one presenter at a time.=A0 With multiple cables, there= is usually a button at each spot, and if you press it you become the prese= nter (most recent request wins is the policy).=A0 Normal social courtesies = handle conflict, so there is no real need for formal floor control.=A0 This= happens even in ordinary webex conferences - if someone grabs the ball whe= n they shouldn't have it, people say something and it gets resolved.=A0= Similarly, if someone needs the ball.=A0=A0 More precisely, the presenting= video system holds the token for the room.=A0 With H.239, the MCU (if ther= e is one) grants it, using whatever policy it wants, and can revoke it at a= ny time.=A0 In point-to-point calls, the far end SHALL grant it upon reques= t, so in that case the turn-taking policy is mandated in the standard. Mult= iple presenters in the same room is up to the local room policy - there is = no standard, and in my opinion none is needed.=A0 The token remains owned b= y the local video system, it is allowed to present whatever local source it= wishes. [/sb]
My answer on application sharing falling "out of favor" related specifically to vendor support for standards-based application sharing
(T.120 in particular) - which I thought was responsive to your original
question. =A0Perhaps I misunderstood it. =A0Anyway there were several
reasons [and perhaps various viewpoints] on why T.120 was dropped,
though I think it is probably not a useful discussion for this list. =A0I know of no other standards-based protocol for application sharing.

I wasn't assuming there was, other than a pure video (and maybe audio) = stream interface. There are other fora for that sort of thing, but its my i= mpression that this is largely a world of proprietary and defacto standards= .


BTW, it is relatively common for web screen sharing to co-exist with the videoconferencing presentation methods. =A0For instance, you can have a
stand-alone webex conference, with someone sharing their laptop screen
for the video participants.[/sb]

I have done this. But it was cumbersome. IIRC, getting the sharing to be vi= sible in the room I was in required using a video cable in addition to usin= g webex sharing.
[sb]With our equipment you could use the = cable if you wished, but it would not be required.=A0 Though generally spea= king, people are used to using projectors for presenting.=A0 Video systems = are providing identical interfaces, so they work the way people expect.=A0 = For instance, in IETF interim meetings the Webex screen is always presented= locally, frequently using a cable.=A0 The chairs may find that cumbersome,= but they certainly come into the meeting expecting to do it anyway.[\sb]


=A0 =A0Of course that is still somewhat cumbersome, but presumably it will=
=A0 =A0be improved over time. Its the UI for driving it that is cumbersome= ,
=A0 =A0not the output.

=A0 =A0A key difference is that if the computer output is via video cable<= br> =A0 =A0into the local room controller, then that is probably responsible =A0 =A0for displaying it locally on a display in the room as well as
=A0 =A0sending it to the remote end. If the users connect their computers<= br> =A0 =A0directly to the MCU, then the capture will come to the room just =A0 =A0like anything else from the MCU.

[sb]The standard model for videoconferencing presentations is a
token-controlled transmission. =A0If you don't have the token, you are<= br> receiving. The local equipment is always responsible for display.
Looping the presentation back through the MCU back to the originating
site wastes bandwidth.

I don't know if web conferencing solutions do this differently or not.<= br> I've always assumed that when I grab the webex "ball" I stop = receiving
desktop images. =A0Certainly there is no reason for the server to send
them back to me.[/sb]

=A0 =A0 =A0 =A0Thanks,
=A0 =A0 =A0 =A0Paul

--047d7b15a8c36877a304bef4476b-- From johaniel@cisco.com Wed May 2 05:06:59 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 038A521F8879 for ; Wed, 2 May 2012 05:06:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r6jKNJ4ASL8A for ; Wed, 2 May 2012 05:06:57 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id E938521F8878 for ; Wed, 2 May 2012 05:06:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=johaniel@cisco.com; l=20529; q=dns/txt; s=iport; t=1335960417; x=1337170017; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=cMvfw8BE65nbnbfwjB0pJP0IZVmK+wjlALdwOxeXPNA=; b=fAOL3nQ8r6e9hDn75jW6PsjeBY+N2he6aSW4X6lrHEouX2pPluoA5ENJ 36KA9adkT1YYVJf3vK6n7viVxtJE4SoRNttY4sxqcKCIfVNeMuQzxFHId 2/jL6ckL/8dDT/2y864lzxDGnTXzpVhwcnbctcUAAZmUDUeN0ywnlvlWS Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Al4FAIgioU+Q/khM/2dsb2JhbABEDoI4rTODAoEHggkBAQEEEgEJEQM4ERACAQgRBAEBCwYXAQYBRQkIAQEEARIIEweFb4F8mkagBZAlYwSkV4Fpgi87gVIGAQEN X-IronPort-AV: E=Sophos;i="4.75,515,1330905600"; d="scan'208,217";a="72249935" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 02 May 2012 12:06:54 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q42C6sm1000980; Wed, 2 May 2012 12:06:54 GMT Received: from xmb-ams-206.cisco.com ([144.254.75.17]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 2 May 2012 14:06:54 +0200 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_01CD285C.104A7220" Date: Wed, 2 May 2012 14:06:53 +0200 Message-ID: <05DD269BD82AA549BC4B2619BBAC466A0109F228@XMB-AMS-206.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] ways of managing presentations in telepresence sessions Thread-Index: Ac0naaU16DP/igkxTxS0u1IIwJ0A2QA8LNiw References: <4F997E6B.7070501@alum.mit.edu><4F9B0D81.4040608@alum.mit.edu><4F9EC454.3060605@alum.mit.edu> From: "Johan Ludvig Nielsen (johaniel)" To: "Stephen Botzko" , "Paul Kyzivat" X-OriginalArrivalTime: 02 May 2012 12:06:54.0339 (UTC) FILETIME=[108CFD30:01CD285C] Cc: CLUE Subject: Re: [clue] ways of managing presentations in telepresence sessions X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2012 12:06:59 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD285C.104A7220 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I just want to remind you all that presentation often means video _and_ audio, for instance a movie clip with a stereo soundtrack. Sometimes presentation means only audio. Hook up your favourite device and share a music clip or an interesting recording. =20 Any presentation audio played back locally must be controlled by, or at least be exactly (in sample sync) known to, the local telepresence system controller. A totally separate endpoint for presentation will therefore cause some practical problems. =20 By the way, one very useful effect of CLUE is the ability for receiving endpoints to distinguish between audio from live talking sources and presentations/recordings. =20 Johan =20 =20 From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Stephen Botzko Sent: 1. mai 2012 09:11 To: Paul Kyzivat Cc: CLUE Subject: Re: [clue] ways of managing presentations in telepresence sessions =20 =20 On Mon, Apr 30, 2012 at 12:56 PM, Paul Kyzivat wrote: On 4/28/12 1:18 PM, Stephen Botzko wrote: [sb] As I mentioned above, the existing solutions usually include a screen-scrape application, so you don't have to use a video cable. This is essentially the same as using Webex for presenting (but not remote control). =20 How are these solutions connected? Does the captured application data go to the local room controller, or to an MCU in the middle of the TP session? Or something else? [sb] They are normally connected to the local room telepresence system. Again, the people in the local room also need to see the presentation, so this is the most direct and also is the most bandwidth efficient approach. Another aspect is that the rooms can and are used purely locally (with no remote systems at all), and presentations also need to work in that situation. BTW I think adding requirements for support of multiple endpoints in the same room is an unwise path - this is not SPLICES, and we have enough to do already. I agree with folks who are saying it is out of scope[/sb] =20 Also, even though Webex allows remote control, in my experience that feature is not used as much as simple presenting. I am not saying it has no value, just that the most common case I see is a simple presentation. =20 That is my experience as well. I wasn't thinking about the multi-user-control aspect. =20 Supporting the video cable still has value, especially if you have guest presenter who does not have access to your local network. Most of those presenters are expecting to use a projector, so they have the cables with them. =20 Surely. In this case, I presume the cable connects to the local room controller. If there are multiple cable connectors (e.g. one at each seat) do they show up as multiple presentation streams? Or is there some sort of switch and floor control? If so, how does one manage the floor control? [sb] Today there is one presenter at a time. With multiple cables, there is usually a button at each spot, and if you press it you become the presenter (most recent request wins is the policy). Normal social courtesies handle conflict, so there is no real need for formal floor control. This happens even in ordinary webex conferences - if someone grabs the ball when they shouldn't have it, people say something and it gets resolved. Similarly, if someone needs the ball. More precisely, the presenting video system holds the token for the room. With H.239, the MCU (if there is one) grants it, using whatever policy it wants, and can revoke it at any time. In point-to-point calls, the far end SHALL grant it upon request, so in that case the turn-taking policy is mandated in the standard. Multiple presenters in the same room is up to the local room policy - there is no standard, and in my opinion none is needed. The token remains owned by the local video system, it is allowed to present whatever local source it wishes. [/sb] My answer on application sharing falling "out of favor" related specifically to vendor support for standards-based application sharing (T.120 in particular) - which I thought was responsive to your original question. Perhaps I misunderstood it. Anyway there were several reasons [and perhaps various viewpoints] on why T.120 was dropped, though I think it is probably not a useful discussion for this list. I know of no other standards-based protocol for application sharing. =20 I wasn't assuming there was, other than a pure video (and maybe audio) stream interface. There are other fora for that sort of thing, but its my impression that this is largely a world of proprietary and defacto standards. =20 BTW, it is relatively common for web screen sharing to co-exist with the videoconferencing presentation methods. For instance, you can have a stand-alone webex conference, with someone sharing their laptop screen for the video participants.[/sb] =20 I have done this. But it was cumbersome. IIRC, getting the sharing to be visible in the room I was in required using a video cable in addition to using webex sharing. [sb]With our equipment you could use the cable if you wished, but it would not be required. Though generally speaking, people are used to using projectors for presenting. Video systems are providing identical interfaces, so they work the way people expect. For instance, in IETF interim meetings the Webex screen is always presented locally, frequently using a cable. The chairs may find that cumbersome, but they certainly come into the meeting expecting to do it anyway.[\sb] =20 Of course that is still somewhat cumbersome, but presumably it will be improved over time. Its the UI for driving it that is cumbersome, not the output. =09 A key difference is that if the computer output is via video cable into the local room controller, then that is probably responsible for displaying it locally on a display in the room as well as sending it to the remote end. If the users connect their computers directly to the MCU, then the capture will come to the room just like anything else from the MCU. =09 [sb]The standard model for videoconferencing presentations is a token-controlled transmission. If you don't have the token, you are receiving. The local equipment is always responsible for display. Looping the presentation back through the MCU back to the originating site wastes bandwidth. =09 I don't know if web conferencing solutions do this differently or not. I've always assumed that when I grab the webex "ball" I stop receiving desktop images. Certainly there is no reason for the server to send them back to me.[/sb] =09 Thanks, Paul =20 ------_=_NextPart_001_01CD285C.104A7220 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I just want to remind you all that presentation often means video = _and_ audio, for instance a movie clip with a stereo soundtrack. = Sometimes presentation means only audio. Hook up your favourite device = and share a music clip or an interesting = recording.

 

Any presentation audio played back locally must be controlled by, or = at least be exactly (in sample sync) known to, the local telepresence = system controller. A totally separate endpoint for presentation will = therefore cause some practical problems.

 

By the way, one very useful effect of CLUE is the ability for = receiving endpoints to distinguish between audio from live talking = sources and presentations/recordings.

 

Johan

 

 

From:= = clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of = Stephen Botzko
Sent: 1. mai 2012 09:11
To: Paul = Kyzivat
Cc: CLUE
Subject: Re: [clue] ways of = managing presentations in telepresence = sessions

 

 

On Mon, Apr 30, 2012 at 12:56 PM, Paul Kyzivat <pkyzivat@alum.mit.edu> = wrote:

On 4/28/12 1:18 PM, Stephen Botzko = wrote:

[sb] As I mentioned above, the = existing solutions usually include a
screen-scrape application, so = you don't have to use a video cable. This
is essentially the same as = using Webex for presenting (but not remote
control).

 

How = are these solutions connected? Does the captured application data go to = the local room controller, or to an MCU in the middle of the TP session? = Or something else?

[sb] They are normally connected to the = local room telepresence system.  Again, the people in the local = room also need to see the presentation, so this is the most direct and = also is the most bandwidth efficient approach.  Another aspect is = that the rooms can and are used purely locally (with no remote systems = at all), and presentations also need to work in that situation.  = BTW I think adding requirements for support of multiple endpoints in the = same room is an unwise path -  this is not SPLICES, and we have = enough to do already.  I agree with folks who are saying it is out = of scope[/sb]

 

Also, even = though Webex allows remote control, in my
experience that feature is = not used as much as simple presenting.  I am
not saying it has = no value, just that the most common case I see is a
simple = presentation.

 

That = is my experience as well. I wasn't thinking about the multi-user-control = aspect.

 

Supporting the video cable still has value, especially = if you have guest
presenter who does not have access to your local = network.  Most of those
presenters are expecting to use a = projector, so they have the cables
with = them.

 

Surely. In this case, I presume the cable connects to = the local room controller. If there are multiple cable connectors (e.g. = one at each seat) do they show up as multiple presentation streams? Or = is there some sort of switch and floor control? If so, how does one = manage the floor control?

[sb] = Today there is one presenter at a time.  With multiple cables, = there is usually a button at each spot, and if you press it you become = the presenter (most recent request wins is the policy).  Normal = social courtesies handle conflict, so there is no real need for formal = floor control.  This happens even in ordinary webex conferences - = if someone grabs the ball when they shouldn't have it, people say = something and it gets resolved.  Similarly, if someone needs the = ball.   More precisely, the presenting video system holds the = token for the room.  With H.239, the MCU (if there is one) grants = it, using whatever policy it wants, and can revoke it at any time.  = In point-to-point calls, the far end SHALL grant it upon request, so in = that case the turn-taking policy is mandated in the standard. Multiple = presenters in the same room is up to the local room policy - there is no = standard, and in my opinion none is needed.  The token remains = owned by the local video system, it is allowed to present whatever local = source it wishes. [/sb]

My answer = on application sharing falling "out of favor" = related
specifically to vendor support for standards-based = application sharing
(T.120 in particular) - which I thought was = responsive to your original
question.  Perhaps I misunderstood = it.  Anyway there were several
reasons [and perhaps various = viewpoints] on why T.120 was dropped,
though I think it is probably = not a useful discussion for this list.  I
know of no other = standards-based protocol for application = sharing.

 

I = wasn't assuming there was, other than a pure video (and maybe audio) = stream interface. There are other fora for that sort of thing, but its = my impression that this is largely a world of proprietary and defacto = standards.

 

BTW, it is relatively common for web screen sharing to = co-exist with the
videoconferencing presentation methods.  For = instance, you can have a
stand-alone webex conference, with someone = sharing their laptop screen
for the video = participants.[/sb]

 

I have = done this. But it was cumbersome. IIRC, getting the sharing to be = visible in the room I was in required using a video cable in addition to = using webex sharing.

[sb]With our equipment you could use the cable if you = wished, but it would not be required.  Though generally speaking, = people are used to using projectors for presenting.  Video systems = are providing identical interfaces, so they work the way people = expect.  For instance, in IETF interim meetings the Webex screen is = always presented locally, frequently using a cable.  The chairs may = find that cumbersome, but they certainly come into the meeting expecting = to do it anyway.[\sb]

 

   Of course that is still somewhat = cumbersome, but presumably it will
   be improved over = time. Its the UI for driving it that is cumbersome,
   not = the output.

   A key difference is that if the computer = output is via video cable
   into the local room = controller, then that is probably responsible
   for = displaying it locally on a display in the room as well as
  =  sending it to the remote end. If the users connect their = computers
   directly to the MCU, then the capture will = come to the room just
   like anything else from the = MCU.

[sb]The standard model for videoconferencing presentations = is a
token-controlled transmission.  If you don't have the = token, you are
receiving. The local equipment is always responsible = for display.
Looping the presentation back through the MCU back to = the originating
site wastes bandwidth.

I don't know if web = conferencing solutions do this differently or not.
I've always = assumed that when I grab the webex "ball" I stop = receiving
desktop images.  Certainly there is no reason for the = server to send
them back to me.[/sb]


       Thanks,
  =      Paul

 

------_=_NextPart_001_01CD285C.104A7220-- From marshall.eubanks@gmail.com Wed May 2 07:52:56 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16A4821F8624 for ; Wed, 2 May 2012 07:52:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.638 X-Spam-Level: X-Spam-Status: No, score=-103.638 tagged_above=-999 required=5 tests=[AWL=-0.039, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PhbS2CTgSOm6 for ; Wed, 2 May 2012 07:52:54 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7B38321F8623 for ; Wed, 2 May 2012 07:52:54 -0700 (PDT) Received: by lagj5 with SMTP id j5so585511lag.31 for ; Wed, 02 May 2012 07:52:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=+qgdpQ/fT5LhCPeJgUmFZmk0vTgcQGRpOFgHAJ7b/vQ=; b=uBfgsyr4dwam9EjM+baQ8x9Zfhrk3ugRzMOgZhYVcmfrxHiBk/3N8NadNJFelWAgVi qcJFvgec6T9nW5urqll6pJwMEmu9IEpFEDaXHN3iS7fcEdwrvwvEOI0CvZHMWxiFWEfS tJSNVD1QpsmRvYDotTuGpMSuyIULRvjlOY45YkoVVEdwrMf/jqLD9NsYsVRAkt28rynd 4B5s8XQzrI8tfpxO+12KNdVntHhmpShOe6jWqKaSMnBaet0ImTub57sVH1Etx0MJ5dVH r3ZzFvLtskq81pbA6e226JtGUXs9tflx62W15krt1T2+kGbjV23rg9NA7F9/9pkX1vHq iEfw== MIME-Version: 1.0 Received: by 10.152.130.138 with SMTP id oe10mr1549503lab.5.1335970373391; Wed, 02 May 2012 07:52:53 -0700 (PDT) Received: by 10.112.56.13 with HTTP; Wed, 2 May 2012 07:52:53 -0700 (PDT) Date: Wed, 2 May 2012 10:52:53 -0400 Message-ID: From: Marshall Eubanks To: clue Content-Type: text/plain; charset=ISO-8859-1 Subject: [clue] Teletouch Demo at 3GSM 2012 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2012 14:52:56 -0000 http://vimeo.com/37734530 http://www.telepresenceoptions.com/2012/04/teletouch_creates_a_futuristic/ This is obviously intended for telepresence. I wonder if this would create any CLUE requirements, such as - whether a screen (or which screens) are touch sensitive and - how the touch sensitivity is configured (are there standards for this) ? Regards Marshall From pkyzivat@alum.mit.edu Wed May 2 08:22:48 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1084721E801F for ; Wed, 2 May 2012 08:22:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.482 X-Spam-Level: X-Spam-Status: No, score=-2.482 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zf5oG+8W8OMI for ; Wed, 2 May 2012 08:22:46 -0700 (PDT) Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [76.96.62.17]) by ietfa.amsl.com (Postfix) with ESMTP id AC0EF21F863F for ; Wed, 2 May 2012 08:22:45 -0700 (PDT) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta10.westchester.pa.mail.comcast.net with comcast id 53Lo1j0031c6gX85A3NgSo; Wed, 02 May 2012 15:22:40 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta23.westchester.pa.mail.comcast.net with comcast id 53Nl1j00K07duvL3j3Nlm3; Wed, 02 May 2012 15:22:46 +0000 Message-ID: <4FA15144.9030307@alum.mit.edu> Date: Wed, 02 May 2012 11:22:44 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "Johan Ludvig Nielsen (johaniel)" References: <4F997E6B.7070501@alum.mit.edu><4F9B0D81.4040608@alum.mit.edu><4F9EC454.3060605@alum.mit.edu> <05DD269BD82AA549BC4B2619BBAC466A0109F228@XMB-AMS-206.cisco.com> In-Reply-To: <05DD269BD82AA549BC4B2619BBAC466A0109F228@XMB-AMS-206.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: CLUE Subject: Re: [clue] ways of managing presentations in telepresence sessions X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2012 15:22:48 -0000 On 5/2/12 8:06 AM, Johan Ludvig Nielsen (johaniel) wrote: > I just want to remind you all that presentation often means video _and_ > audio, for instance a movie clip with a stereo soundtrack. Sometimes > presentation means only audio. Hook up your favourite device and share a > music clip or an interesting recording. > > Any presentation audio played back locally must be controlled by, or at > least be exactly (in sample sync) known to, the local telepresence > system controller. A totally separate endpoint for presentation will > therefore cause some practical problems. > > By the way, one very useful effect of CLUE is the ability for receiving > endpoints to distinguish between audio from live talking sources and > presentations/recordings. I'm not sure I understand the point you are making. Certainly it is true that a presentation may consist of audio and video. But its not just presentations that can contain paired audio and video. When we have many audio and video captures, there could be several pairs. RFC3388 provides a way (a=mid:ls) to indicate when lip sync is required. Do we need more than that? Should advertisements indicate desirable audio/video pairings so that selection can take that into account? Thanks, Paul > Johan > > *From:*clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On Behalf > Of *Stephen Botzko > *Sent:* 1. mai 2012 09:11 > *To:* Paul Kyzivat > *Cc:* CLUE > *Subject:* Re: [clue] ways of managing presentations in telepresence > sessions > > On Mon, Apr 30, 2012 at 12:56 PM, Paul Kyzivat > wrote: > > On 4/28/12 1:18 PM, Stephen Botzko wrote: > > [sb] As I mentioned above, the existing solutions usually include a > screen-scrape application, so you don't have to use a video cable. This > is essentially the same as using Webex for presenting (but not remote > control). > > How are these solutions connected? Does the captured application data go > to the local room controller, or to an MCU in the middle of the TP > session? Or something else? > > [sb] They are normally connected to the local room telepresence system. > Again, the people in the local room also need to see the presentation, > so this is the most direct and also is the most bandwidth efficient > approach. Another aspect is that the rooms can and are used purely > locally (with no remote systems at all), and presentations also need to > work in that situation. BTW I think adding requirements for support of > multiple endpoints in the same room is an unwise path - this is not > SPLICES, and we have enough to do already. I agree with folks who are > saying it is out of scope[/sb] > > Also, even though Webex allows remote control, in my > experience that feature is not used as much as simple > presenting. I am > not saying it has no value, just that the most common case I see > is a > simple presentation. > > That is my experience as well. I wasn't thinking about the > multi-user-control aspect. > > Supporting the video cable still has value, especially if you > have guest > presenter who does not have access to your local network. Most > of those > presenters are expecting to use a projector, so they have the cables > with them. > > Surely. In this case, I presume the cable connects to the local room > controller. If there are multiple cable connectors (e.g. one at each > seat) do they show up as multiple presentation streams? Or is there > some sort of switch and floor control? If so, how does one manage > the floor control? > > [sb] Today there is one presenter at a time. With multiple cables, > there is usually a button at each spot, and if you press it you > become the presenter (most recent request wins is the policy). > Normal social courtesies handle conflict, so there is no real need > for formal floor control. This happens even in ordinary webex > conferences - if someone grabs the ball when they shouldn't have it, > people say something and it gets resolved. Similarly, if someone > needs the ball. More precisely, the presenting video system holds > the token for the room. With H.239, the MCU (if there is one) grants > it, using whatever policy it wants, and can revoke it at any time. > In point-to-point calls, the far end SHALL grant it upon request, so > in that case the turn-taking policy is mandated in the standard. > Multiple presenters in the same room is up to the local room policy > - there is no standard, and in my opinion none is needed. The token > remains owned by the local video system, it is allowed to present > whatever local source it wishes. [/sb] > > My answer on application sharing falling "out of favor" related > specifically to vendor support for standards-based application > sharing > (T.120 in particular) - which I thought was responsive to your > original > question. Perhaps I misunderstood it. Anyway there were several > reasons [and perhaps various viewpoints] on why T.120 was dropped, > though I think it is probably not a useful discussion for this > list. I > know of no other standards-based protocol for application sharing. > > I wasn't assuming there was, other than a pure video (and maybe > audio) stream interface. There are other fora for that sort of > thing, but its my impression that this is largely a world of > proprietary and defacto standards. > > BTW, it is relatively common for web screen sharing to co-exist > with the > videoconferencing presentation methods. For instance, you can have a > stand-alone webex conference, with someone sharing their laptop > screen > for the video participants.[/sb] > > I have done this. But it was cumbersome. IIRC, getting the sharing > to be visible in the room I was in required using a video cable in > addition to using webex sharing. > > [sb]With our equipment you could use the cable if you wished, but it > would not be required. Though generally speaking, people are used to > using projectors for presenting. Video systems are providing identical > interfaces, so they work the way people expect. For instance, in IETF > interim meetings the Webex screen is always presented locally, > frequently using a cable. The chairs may find that cumbersome, but they > certainly come into the meeting expecting to do it anyway.[\sb] > > Of course that is still somewhat cumbersome, but presumably it will > be improved over time. Its the UI for driving it that is cumbersome, > not the output. > > A key difference is that if the computer output is via video cable > into the local room controller, then that is probably responsible > for displaying it locally on a display in the room as well as > sending it to the remote end. If the users connect their computers > directly to the MCU, then the capture will come to the room just > like anything else from the MCU. > > [sb]The standard model for videoconferencing presentations is a > token-controlled transmission. If you don't have the token, you are > receiving. The local equipment is always responsible for display. > Looping the presentation back through the MCU back to the > originating > site wastes bandwidth. > > I don't know if web conferencing solutions do this differently > or not. > I've always assumed that when I grab the webex "ball" I stop > receiving > desktop images. Certainly there is no reason for the server to send > them back to me.[/sb] > > > Thanks, > Paul > From mary.ietf.barnes@gmail.com Wed May 2 08:27:19 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CCD321F863F for ; Wed, 2 May 2012 08:27:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.557 X-Spam-Level: X-Spam-Status: No, score=-103.557 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e4pKD3j9H5-6 for ; Wed, 2 May 2012 08:27:18 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1C85621F8634 for ; Wed, 2 May 2012 08:27:18 -0700 (PDT) Received: by yhq56 with SMTP id 56so971391yhq.31 for ; Wed, 02 May 2012 08:27:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=uLSG+aawAVzNIH+epEusUECRH2/2Bexh5qacpE5RNRY=; b=UME7A91aKaOIxNhoAOhvhhEENrm5YqsI6E+lKxvl1fCd3zaC4kDl4hLP8TiPUu5DZF 0HUeS7lLeEIZZ9PyhoPjjsrqroUyBKmlIfbxMnMOIUQp+cRe+YEccLzOC+wwAwzYje9Q vqp7ZZT3YQiv2iBB5tc4EMZqO1zzWR+YfeqD2p7M4SHVNewbVdJBaTHOcEDgxBYitTzb mrYx3CsAkfCL5gvFR8YhJykats9tyHd3Sdreq7z7rjQYwg8em0W7RsiSNECqf20OLzBz PRR8BUrU2NwQHbhIsdRifi9ENeIy2QIWWQaLVhqw+VwJDoY9JrdSRsb8raxpjYS+lOvr 5OEA== MIME-Version: 1.0 Received: by 10.236.168.42 with SMTP id j30mr31033951yhl.25.1335972437724; Wed, 02 May 2012 08:27:17 -0700 (PDT) Received: by 10.236.176.102 with HTTP; Wed, 2 May 2012 08:27:17 -0700 (PDT) In-Reply-To: References: Date: Wed, 2 May 2012 10:27:17 -0500 Message-ID: From: Mary Barnes To: Marshall Eubanks Content-Type: multipart/alternative; boundary=20cf305b13de948f7704bf0f52d4 Cc: clue Subject: Re: [clue] Teletouch Demo at 3GSM 2012 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2012 15:27:19 -0000 --20cf305b13de948f7704bf0f52d4 Content-Type: text/plain; charset=ISO-8859-1 I would think this functionality fits into a next stage for CLUE as it's certainly not widely implemented in today's telepresence systems, which is the current charter for CLUE. Mary. On Wed, May 2, 2012 at 9:52 AM, Marshall Eubanks wrote: > http://vimeo.com/37734530 > > http://www.telepresenceoptions.com/2012/04/teletouch_creates_a_futuristic/ > > This is obviously intended for telepresence. > > I wonder if this would create any CLUE requirements, such as > > - whether a screen (or which screens) are touch sensitive and > - how the touch sensitivity is configured (are there standards for this) ? > > Regards > Marshall > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > --20cf305b13de948f7704bf0f52d4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I would think this functionality fits into a next stage for CLUE as it'= s certainly not widely implemented in today's telepresence systems, whi= ch is the current charter for CLUE.

Mary.

On Wed, May 2, 2012 at 9:52 AM, Marshall Eubanks <marshall.eubank= s@gmail.com> wrote:
http://vimeo.com/37= 734530

http://www.telepresenceoptions.com/2012/04/te= letouch_creates_a_futuristic/

This is obviously intended for telepresence.

I wonder if this would create any CLUE requirements, such as

- whether a screen (or which screens) are touch sensitive and
- how the touch sensitivity is configured (are there standards for this) ?<= br>
Regards
Marshall
_______________________________________________
clue mailing list
clue@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/clue

--20cf305b13de948f7704bf0f52d4-- From pkyzivat@alum.mit.edu Wed May 2 08:38:09 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6226021E8019 for ; Wed, 2 May 2012 08:38:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.484 X-Spam-Level: X-Spam-Status: No, score=-2.484 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I9CD4RkBet5p for ; Wed, 2 May 2012 08:38:06 -0700 (PDT) Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [76.96.62.80]) by ietfa.amsl.com (Postfix) with ESMTP id AD05521F842D for ; Wed, 2 May 2012 08:38:05 -0700 (PDT) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta08.westchester.pa.mail.comcast.net with comcast id 53Lq1j0031c6gX8583e2Gt; Wed, 02 May 2012 15:38:02 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta23.westchester.pa.mail.comcast.net with comcast id 53e51j00f07duvL3j3e5S9; Wed, 02 May 2012 15:38:05 +0000 Message-ID: <4FA154DC.3090305@alum.mit.edu> Date: Wed, 02 May 2012 11:38:04 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: clue@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] Teletouch Demo at 3GSM 2012 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2012 15:38:09 -0000 Interesting demo. But it raises many questions for me. The metaphor of being on two sides of a window doesn't really work for much application content. Does the woman on the other side of the screen see the *back* of the text displays, with the text inverted and backward? There will be lots of new things coming along. Some with succeed and some won't. We probably don't want to do anything specific for a particular technology like this, but clue should be extensible for things like this. Figuring out if we have sufficient framework for extension is the hard part. On 5/2/12 10:52 AM, Marshall Eubanks wrote: > http://vimeo.com/37734530 > > http://www.telepresenceoptions.com/2012/04/teletouch_creates_a_futuristic/ > > This is obviously intended for telepresence. > > I wonder if this would create any CLUE requirements, such as > > - whether a screen (or which screens) are touch sensitive and > - how the touch sensitivity is configured (are there standards for this) ? I don't know anything about this. If anybody does please speak up. Thanks, Paul From stephen.botzko@gmail.com Wed May 2 23:54:58 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 320DA21F85F8 for ; Wed, 2 May 2012 23:54:58 -0700 (PDT) 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.459, BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8NSig5CFcs8k for ; Wed, 2 May 2012 23:54:57 -0700 (PDT) Received: from mail-pz0-f52.google.com (mail-pz0-f52.google.com [209.85.210.52]) by ietfa.amsl.com (Postfix) with ESMTP id E8D7421F85A2 for ; Wed, 2 May 2012 23:54:56 -0700 (PDT) Received: by dadz9 with SMTP id z9so1418438dad.39 for ; Wed, 02 May 2012 23:54:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=CjJD5n5IMF2iuGDHFBIQ9y8aorwmemXPZHAtnN8jLls=; b=zYLnf4rK9LKj4lZgWWuqfMXMi6ucNu3wRnkiTy0jj6lzZm4RPs34jMuTfhbiN75IBB e38CLm1g7AkWHEodtf2Tl+w9odlUVe96MFkkiwBj1JZRTTpv1iPjH51rAHq6T0O6IDN9 DpURSAXtfGm5OEj2wL9cqBMQDn31OJypq1v3RNbrs/IRWwSi36hjACTodGR3DOno87OU /zAloZRVF3QZmyd9/5OM1WhZMP4b2SU8CoLJLgy1KJmiWLRuSmuICumRWouAlJA+mwo6 dYlaPeJhoNr+ANbMxgtjXiLExVlOtUwXqZzsRxLK4BzX9EQ5kVMifVFMfmkoVdtX2BlK 5CfQ== MIME-Version: 1.0 Received: by 10.68.190.229 with SMTP id gt5mr4658727pbc.59.1336028091042; Wed, 02 May 2012 23:54:51 -0700 (PDT) Received: by 10.68.239.228 with HTTP; Wed, 2 May 2012 23:54:50 -0700 (PDT) In-Reply-To: <4FA154DC.3090305@alum.mit.edu> References: <4FA154DC.3090305@alum.mit.edu> Date: Thu, 3 May 2012 08:54:50 +0200 Message-ID: From: Stephen Botzko To: Paul Kyzivat Content-Type: multipart/alternative; boundary=e89a8ff1c818c6cb8504bf1c47ff Cc: clue@ietf.org Subject: Re: [clue] Teletouch Demo at 3GSM 2012 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 03 May 2012 06:54:58 -0000 --e89a8ff1c818c6cb8504bf1c47ff Content-Type: text/plain; charset=ISO-8859-1 Clearly the text cannot be inverted for collaboration, so the display is not really modeling a window. It seems to me that this will result in some perceptual confusion. When she touches a letter on her left, that same letter is rendered on my left - so she would not appear to be touching the correct letter. That can be "corrected" by reversing left and right in the woman's video capture. That simply moves the perceptual confusion - if there is an analog clock on the wall behind the woman, it will look like it is running backwards. Similarly if the woman were wearing a name tag (or had a logo on her clothing), the text would be reversed. So while this makes an interesting demo, there are some problems inherent to the approach. Thinking speculatively about future CLUE extensions - The capture includes an overlay, which is intended to be rendered with the capture. I believe our current framework could be easily extended to include this in the future. It could have some implications on the RTP/transport level if the overlay is not transported as part of the capture. -One might need to specify a left-right reversal in the capture. That is certainly easy enough to do, though it creates the perceptual issues noted above. Stephen Botzko On Wed, May 2, 2012 at 5:38 PM, Paul Kyzivat wrote: > Interesting demo. But it raises many questions for me. The metaphor of > being on two sides of a window doesn't really work for much application > content. Does the woman on the other side of the screen see the *back* of > the text displays, with the text inverted and backward? > > There will be lots of new things coming along. Some with succeed and some > won't. We probably don't want to do anything specific for a particular > technology like this, but clue should be extensible for things like this. > Figuring out if we have sufficient framework for extension is the hard part. > > > On 5/2/12 10:52 AM, Marshall Eubanks wrote: > >> http://vimeo.com/37734530 >> >> http://www.**telepresenceoptions.com/2012/**04/teletouch_creates_a_** >> futuristic/ >> >> This is obviously intended for telepresence. >> >> I wonder if this would create any CLUE requirements, such as >> >> - whether a screen (or which screens) are touch sensitive and >> - how the touch sensitivity is configured (are there standards for this) ? >> > > I don't know anything about this. If anybody does please speak up. > > Thanks, > Paul > > ______________________________**_________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/**listinfo/clue > --e89a8ff1c818c6cb8504bf1c47ff Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Clearly the text cannot be inverted for collaboration, so the display is no= t really modeling a window.

It seems to me that this will result in= some perceptual confusion.=A0 When she touches a letter on her left, that = same letter is rendered on my left - so she would not appear to be touching= the correct letter. That can be "corrected" by reversing left an= d right in the woman's video capture.=A0 That simply moves the perceptu= al confusion - if there is an analog clock on the wall behind the woman, it= will look like it is running backwards.=A0 Similarly if the woman were wea= ring a name tag (or had a logo on her clothing), the text would be reversed= .

So while this makes an interesting demo, there are some problems inhere= nt to the approach.

Thinking speculatively about future CLUE extensi= ons
- The capture includes an overlay, which is intended to be rendered = with the capture.=A0 I believe our current framework could be easily extend= ed to include this in the future.=A0 It could have some implications on the= RTP/transport level=A0 if the overlay is not transported as part of the ca= pture.

-One might need to specify a left-right reversal in the capture. That i= s certainly easy enough to do, though it creates the perceptual issues note= d above.

Stephen Botzko

On Wed, Ma= y 2, 2012 at 5:38 PM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
Interesting demo. But it raises many questio= ns for me. The metaphor of being on two sides of a window doesn't reall= y work for much application content. Does the woman on the other side of th= e screen see the *back* of the text displays, with the text inverted and ba= ckward?

There will be lots of new things coming along. Some with succeed and some w= on't. We probably don't want to do anything specific for a particul= ar technology like this, but clue should be extensible for things like this= . Figuring out if we have sufficient framework for extension is the hard pa= rt.


On 5/2/12 10:52 AM, Marshall Eubanks wrote:
http://vimeo.com/37= 734530

http://www.telepresenceoptions.com/201= 2/04/teletouch_creates_a_futuristic/

This is obviously intended for telepresence.

I wonder if this would create any CLUE requirements, such as

- whether a screen (or which screens) are touch sensitive and
- how the touch sensitivity is configured (are there standards for this) ?<= br>

I don't know anything about this. If anybody does please speak up.

=A0 =A0 =A0 =A0Thanks,
=A0 =A0 =A0 =A0Paul

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

--e89a8ff1c818c6cb8504bf1c47ff-- From johaniel@cisco.com Thu May 3 06:02:49 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A047F21F8568 for ; Thu, 3 May 2012 06:02:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G48W1jBhBvyL for ; Thu, 3 May 2012 06:02:48 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id CCFD521F8565 for ; Thu, 3 May 2012 06:02:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=johaniel@cisco.com; l=9744; q=dns/txt; s=iport; t=1336050167; x=1337259767; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=jR+RqOeQcyazwlDvoSxq4etiTkvFRissBKunOZ9qDFA=; b=Z23zW1BIU7YKbBMeKPegBlgTRYB898OOCqsRnU6ZrYJMCZv8ljtVr6uf tfPUI2SgKDNjyNwvRoro7zRH5L+GwQ3xwx+5wPwrrZQqiPnWar+7H4ZWy 6L4CrC2JyHhWXAYZUIolgVJ/skwPsXzsCLTdgNpROS/BK1Jjk3IeBB8J/ A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAJ2Bok+Q/khL/2dsb2JhbABFDrJlgQeCCQEBAQMBEgEdCi4RBQcEAgEIDgMEAQEBCgYFEgEGAUUJCAEBBBMIEweFb4F3BZpkoBSNV4JOYwSkV4Fpgi87gVIGAQEN X-IronPort-AV: E=Sophos;i="4.75,523,1330905600"; d="scan'208";a="136938219" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 03 May 2012 13:02:25 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q43D2Pux030686; Thu, 3 May 2012 13:02:25 GMT Received: from xmb-ams-206.cisco.com ([144.254.75.17]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 3 May 2012 15:02:25 +0200 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: Thu, 3 May 2012 15:02:23 +0200 Message-ID: <05DD269BD82AA549BC4B2619BBAC466A0109F407@XMB-AMS-206.cisco.com> In-Reply-To: <4FA15144.9030307@alum.mit.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] ways of managing presentations in telepresence sessions Thread-Index: Ac0od3X3UfwvQJL7TDa0MMR12dlCqwAjSbtg References: <4F997E6B.7070501@alum.mit.edu><4F9B0D81.4040608@alum.mit.edu><4F9EC454.3060605@alum.mit.edu> <05DD269BD82AA549BC4B2619BBAC466A0109F228@XMB-AMS-206.cisco.com> <4FA15144.9030307@alum.mit.edu> From: "Johan Ludvig Nielsen (johaniel)" To: "Paul Kyzivat" X-OriginalArrivalTime: 03 May 2012 13:02:25.0086 (UTC) FILETIME=[FC3E65E0:01CD292C] Cc: CLUE Subject: Re: [clue] ways of managing presentations in telepresence sessions X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 03 May 2012 13:02:49 -0000 Sorry for being unclear. I am commenting on the implied option of rendering presentation on a separate system, either on one or several computers or a dedicated endpoint separate from the telepresence system in the room. My main point is that all audio belonging to a conference and being played back in a room must be controlled by or at least known to the audio processing unit sending audio _from_ that room. This is to avoid echo or multi-path problems. One example of such a problem is if a presentation in the form of a movie with a soundtrack is played back on a computer separate from the telepresence system in the room. The microphone system in the room will pick up the sound from the computer's loudspeakers and happily transmit that as voice into the conference. The presentation audio is then delivered to other sites through two different paths with different delays, one of them with poor quality. The other (and totally separate) point I am making is that with CLUE we will have the ability to send presentation audio as a separate stream, and that we are happy about that. Today locally input presentation audio is most often mixed with the mic signal and sent in the main audio stream (which can be stereo). There is no H.239 equivalent for audio. Regards Johan -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]=20 Sent: 2. mai 2012 17:23 To: Johan Ludvig Nielsen (johaniel) Cc: Stephen Botzko; CLUE Subject: Re: [clue] ways of managing presentations in telepresence sessions On 5/2/12 8:06 AM, Johan Ludvig Nielsen (johaniel) wrote: > I just want to remind you all that presentation often means video=20 > _and_ audio, for instance a movie clip with a stereo soundtrack.=20 > Sometimes presentation means only audio. Hook up your favourite device > and share a music clip or an interesting recording. > > Any presentation audio played back locally must be controlled by, or=20 > at least be exactly (in sample sync) known to, the local telepresence=20 > system controller. A totally separate endpoint for presentation will=20 > therefore cause some practical problems. > > By the way, one very useful effect of CLUE is the ability for=20 > receiving endpoints to distinguish between audio from live talking=20 > sources and presentations/recordings. I'm not sure I understand the point you are making. Certainly it is true that a presentation may consist of audio and video. But its not just presentations that can contain paired audio and video. When we have many audio and video captures, there could be several pairs. RFC3388 provides a way (a=3Dmid:ls) to indicate when lip sync is = required. Do we need more than that? Should advertisements indicate desirable audio/video pairings so that selection can take that into account? Thanks, Paul > Johan > > *From:*clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On Behalf > Of *Stephen Botzko > *Sent:* 1. mai 2012 09:11 > *To:* Paul Kyzivat > *Cc:* CLUE > *Subject:* Re: [clue] ways of managing presentations in telepresence=20 > sessions > > On Mon, Apr 30, 2012 at 12:56 PM, Paul Kyzivat > wrote: > > On 4/28/12 1:18 PM, Stephen Botzko wrote: > > [sb] As I mentioned above, the existing solutions usually include a=20 > screen-scrape application, so you don't have to use a video cable.=20 > This is essentially the same as using Webex for presenting (but not=20 > remote control). > > How are these solutions connected? Does the captured application data=20 > go to the local room controller, or to an MCU in the middle of the TP=20 > session? Or something else? > > [sb] They are normally connected to the local room telepresence system. > Again, the people in the local room also need to see the presentation, > so this is the most direct and also is the most bandwidth efficient=20 > approach. Another aspect is that the rooms can and are used purely=20 > locally (with no remote systems at all), and presentations also need=20 > to work in that situation. BTW I think adding requirements for support > of multiple endpoints in the same room is an unwise path - this is not > SPLICES, and we have enough to do already. I agree with folks who are=20 > saying it is out of scope[/sb] > > Also, even though Webex allows remote control, in my > experience that feature is not used as much as simple > presenting. I am > not saying it has no value, just that the most common case I see > is a > simple presentation. > > That is my experience as well. I wasn't thinking about the > multi-user-control aspect. > > Supporting the video cable still has value, especially if you > have guest > presenter who does not have access to your local network. Most > of those > presenters are expecting to use a projector, so they have the cables > with them. > > Surely. In this case, I presume the cable connects to the local room > controller. If there are multiple cable connectors (e.g. one at each > seat) do they show up as multiple presentation streams? Or is there > some sort of switch and floor control? If so, how does one manage > the floor control? > > [sb] Today there is one presenter at a time. With multiple cables, > there is usually a button at each spot, and if you press it you > become the presenter (most recent request wins is the policy). > Normal social courtesies handle conflict, so there is no real need > for formal floor control. This happens even in ordinary webex > conferences - if someone grabs the ball when they shouldn't have it, > people say something and it gets resolved. Similarly, if someone > needs the ball. More precisely, the presenting video system holds > the token for the room. With H.239, the MCU (if there is one) grants > it, using whatever policy it wants, and can revoke it at any time. > In point-to-point calls, the far end SHALL grant it upon request, so > in that case the turn-taking policy is mandated in the standard. > Multiple presenters in the same room is up to the local room policy > - there is no standard, and in my opinion none is needed. The token > remains owned by the local video system, it is allowed to present > whatever local source it wishes. [/sb] > > My answer on application sharing falling "out of favor" related > specifically to vendor support for standards-based application > sharing > (T.120 in particular) - which I thought was responsive to your > original > question. Perhaps I misunderstood it. Anyway there were several > reasons [and perhaps various viewpoints] on why T.120 was dropped, > though I think it is probably not a useful discussion for this > list. I > know of no other standards-based protocol for application sharing. > > I wasn't assuming there was, other than a pure video (and maybe > audio) stream interface. There are other fora for that sort of > thing, but its my impression that this is largely a world of > proprietary and defacto standards. > > BTW, it is relatively common for web screen sharing to co-exist > with the > videoconferencing presentation methods. For instance, you can have a > stand-alone webex conference, with someone sharing their laptop > screen > for the video participants.[/sb] > > I have done this. But it was cumbersome. IIRC, getting the sharing > to be visible in the room I was in required using a video cable in > addition to using webex sharing. > > [sb]With our equipment you could use the cable if you wished, but it=20 > would not be required. Though generally speaking, people are used to=20 > using projectors for presenting. Video systems are providing identical > interfaces, so they work the way people expect. For instance, in IETF=20 > interim meetings the Webex screen is always presented locally,=20 > frequently using a cable. The chairs may find that cumbersome, but=20 > they certainly come into the meeting expecting to do it anyway.[\sb] > > Of course that is still somewhat cumbersome, but presumably it will > be improved over time. Its the UI for driving it that is cumbersome, > not the output. > > A key difference is that if the computer output is via video cable > into the local room controller, then that is probably responsible > for displaying it locally on a display in the room as well as > sending it to the remote end. If the users connect their computers > directly to the MCU, then the capture will come to the room just > like anything else from the MCU. > > [sb]The standard model for videoconferencing presentations is a > token-controlled transmission. If you don't have the token, you are > receiving. The local equipment is always responsible for display. > Looping the presentation back through the MCU back to the > originating > site wastes bandwidth. > > I don't know if web conferencing solutions do this differently > or not. > I've always assumed that when I grab the webex "ball" I stop > receiving > desktop images. Certainly there is no reason for the server to send > them back to me.[/sb] > > > Thanks, > Paul > From espeberg@cisco.com Thu May 3 06:25:22 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1AA721F8595 for ; Thu, 3 May 2012 06:25:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.598 X-Spam-Level: X-Spam-Status: No, score=-11.598 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VIG+IGz3eCTI for ; Thu, 3 May 2012 06:25:20 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 5FED521F8592 for ; Thu, 3 May 2012 06:25:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=espeberg@cisco.com; l=15504; q=dns/txt; s=iport; t=1336051519; x=1337261119; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=LEY90X03swca4OowSEemJJWezNqTlD7guZxIwfr3Lqg=; b=kAMPn4uGg+I99HnTtseVIslGwlo271szHW/lQ/itxhUIG7KlTBM2A9GW 72bysptea46PwtvUfhj+SiF9d90GbrgCjeALv43B+Fo8oLIPBv0F683wV m6O+blio0GjdTpV8XPpMZ0tX5WtA2e0laCCBUMa1zxw7aO5fGfL/+plgy o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkAFADyGok+Q/khL/2dsb2JhbABFDoI4pmWJSYEHggkBAQEEAQEBDwEJEQM+CxACAQgRBAEBCwYXAQYBJh8JCAEBBAESCBqHawuaYaAZkCVjBJcPijGDF4Fpgi87 X-IronPort-AV: E=Sophos;i="4.75,523,1330905600"; d="scan'208,217";a="136941119" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 03 May 2012 13:25:18 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q43DPHbY003174; Thu, 3 May 2012 13:25:17 GMT Received: from xmb-ams-214.cisco.com ([144.254.75.25]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 3 May 2012 15:25:17 +0200 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_01CD2930.2DC5BE7E" Date: Thu, 3 May 2012 15:25:15 +0200 Message-ID: <92DF9533227FC14F946C7321074B8C9E012A113B@XMB-AMS-214.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] Teletouch Demo at 3GSM 2012 Thread-Index: Ac0o+aslkqU5A17zRtC/AZGJWgO+uAAJZm6Q References: <4FA154DC.3090305@alum.mit.edu> From: "Espen Berger (espeberg)" To: "Stephen Botzko" , "Paul Kyzivat" X-OriginalArrivalTime: 03 May 2012 13:25:17.0181 (UTC) FILETIME=[2E137AD0:01CD2930] Cc: clue@ietf.org Subject: Re: [clue] Teletouch Demo at 3GSM 2012 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 03 May 2012 13:25:22 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD2930.2DC5BE7E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The demo is a good example of how a annotation/collaboration/touch could work with CLUE.=20 =20 I think the main thing CLUE should offer is naming conventions for streams and extension mechanisms to allow for other protocols to extends from CLUE version 1. =20 =20 An annotation protocol could typically integrate with CLUE to do things like=20 * Which streams do I refer to locally (e.g. either 'main' or 'slides')=20 * Which segment do I refer to, e.g. middle segment of 'main'=20 * As a receiver you want to overlay on top video from a named participants, and eventually a given segment.=20 =20 Regards=20 =20 -Espen=20 =20 =20 From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Stephen Botzko Sent: 3. mai 2012 08:55 To: Paul Kyzivat Cc: clue@ietf.org Subject: Re: [clue] Teletouch Demo at 3GSM 2012 =20 Clearly the text cannot be inverted for collaboration, so the display is not really modeling a window.=20 It seems to me that this will result in some perceptual confusion. When she touches a letter on her left, that same letter is rendered on my left - so she would not appear to be touching the correct letter. That can be "corrected" by reversing left and right in the woman's video capture. That simply moves the perceptual confusion - if there is an analog clock on the wall behind the woman, it will look like it is running backwards. Similarly if the woman were wearing a name tag (or had a logo on her clothing), the text would be reversed. So while this makes an interesting demo, there are some problems inherent to the approach. Thinking speculatively about future CLUE extensions - The capture includes an overlay, which is intended to be rendered with the capture. I believe our current framework could be easily extended to include this in the future. It could have some implications on the RTP/transport level if the overlay is not transported as part of the capture. -One might need to specify a left-right reversal in the capture. That is certainly easy enough to do, though it creates the perceptual issues noted above. Stephen Botzko On Wed, May 2, 2012 at 5:38 PM, Paul Kyzivat wrote: Interesting demo. But it raises many questions for me. The metaphor of being on two sides of a window doesn't really work for much application content. Does the woman on the other side of the screen see the *back* of the text displays, with the text inverted and backward? There will be lots of new things coming along. Some with succeed and some won't. We probably don't want to do anything specific for a particular technology like this, but clue should be extensible for things like this. Figuring out if we have sufficient framework for extension is the hard part. On 5/2/12 10:52 AM, Marshall Eubanks wrote: http://vimeo.com/37734530 http://www.telepresenceoptions.com/2012/04/teletouch_creates_a_futuristi c/ This is obviously intended for telepresence. I wonder if this would create any CLUE requirements, such as - whether a screen (or which screens) are touch sensitive and - how the touch sensitivity is configured (are there standards for this) ? =20 I don't know anything about this. If anybody does please speak up. Thanks, Paul _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue =20 ------_=_NextPart_001_01CD2930.2DC5BE7E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The demo is a good example of how a annotation/collaboration/touch = could work with CLUE.

 

I think the main thing CLUE should offer is naming conventions for = streams and extension mechanisms to allow for other protocols to extends = from CLUE version 1.  

 

An annotation protocol could typically integrate with CLUE to do = things like

·         = Which streams do I refer to locally (e.g. either ‘main’ = or ‘slides’)

·         = Which segment do I refer to, e.g. middle segment of = ‘main’

·         = As a receiver you want to overlay on top video from a named = participants, and eventually a given segment.

 

Regards

 

-Espen

 

 

From:= clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] = On Behalf Of Stephen Botzko
Sent: 3. mai 2012 = 08:55
To: Paul Kyzivat
Cc: clue@ietf.org
Subject: Re: = [clue] Teletouch Demo at 3GSM 2012

 

Clearly the text cannot be inverted for = collaboration, so the display is not really modeling a window. =

It seems to me that this will result in some perceptual = confusion.  When she touches a letter on her left, that same letter = is rendered on my left - so she would not appear to be touching the = correct letter. That can be "corrected" by reversing left and = right in the woman's video capture.  That simply moves the = perceptual confusion - if there is an analog clock on the wall behind = the woman, it will look like it is running backwards.  Similarly if = the woman were wearing a name tag (or had a logo on her clothing), the = text would be reversed.

So while this makes an interesting demo, = there are some problems inherent to the approach.

Thinking = speculatively about future CLUE extensions
- The capture includes an = overlay, which is intended to be rendered with the capture.  I = believe our current framework could be easily extended to include this = in the future.  It could have some implications on the = RTP/transport level  if the overlay is not transported as part of = the capture.

-One might need to specify a left-right reversal in = the capture. That is certainly easy enough to do, though it creates the = perceptual issues noted above.

Stephen = Botzko

On Wed, May 2, 2012 at = 5:38 PM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:

Interesting demo. But it raises many questions for me. = The metaphor of being on two sides of a window doesn't really work for = much application content. Does the woman on the other side of the screen = see the *back* of the text displays, with the text inverted and = backward?

There will be lots of new things coming along. Some = with succeed and some won't. We probably don't want to do anything = specific for a particular technology like this, but clue should be = extensible for things like this. Figuring out if we have sufficient = framework for extension is the hard part.



On 5/2/12 10:52 AM, Marshall Eubanks = wrote:

http://vimeo.com/37734530

http://www.telepresenceoptions.com/2012/04/teletouch_cr= eates_a_futuristic/

This is obviously intended for = telepresence.

I wonder if this would create any CLUE = requirements, such as

- whether a screen (or which screens) are = touch sensitive and
- how the touch sensitivity is configured (are = there standards for this) ?

 

I = don't know anything about this. If anybody does please speak = up.

       Thanks,
      =  Paul


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

 

------_=_NextPart_001_01CD2930.2DC5BE7E-- From ron.even.tlv@gmail.com Thu May 3 07:27:14 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0C2421F85C5 for ; Thu, 3 May 2012 07:27:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.222 X-Spam-Level: X-Spam-Status: No, score=-2.222 tagged_above=-999 required=5 tests=[AWL=1.377, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e8IaEagRmGd5 for ; Thu, 3 May 2012 07:27:13 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 47B7A21F85C2 for ; Thu, 3 May 2012 07:27:13 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so1215693wgb.13 for ; Thu, 03 May 2012 07:27:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; 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; bh=p07uhJn7ikD+Ok9+vOvq57lp1A3bsoj4Hy5isU8Yh3c=; b=o5cCHcIA43lFX0r5ulFn1zqhLXCKRADQsSf6HSspeXnU/k7bY7CG6Tij3JZxV3g4nL EoiG25mE4DD/OxDeZ3njjh0kTToro8QzcyvVDGipb1OMEQzdCTG+nq0JmbBNVzKT9TpV g0vkY99g4knjlovG/+Iq5iEwxl1K3tf3inWWLyTLb3cZoTXIblYPWe2rzh3H52QnFTlJ M+ooqGM+a9dKuPsT5vzMZ0Z4DSYR+p9xtRISYparQ5vuKRfWHmUxILdqKW6nWlC/b1Ec 8AwyYljmfuENyT3QAkbHFmOILkOJMKpqsCFnlT/2p+L/0gEVq0WcXqNcJkM/reRer2Ia 7t3g== Received: by 10.216.212.78 with SMTP id x56mr1549163weo.36.1336055231838; Thu, 03 May 2012 07:27:11 -0700 (PDT) Received: from windows8d787f9 ([156.106.233.108]) by mx.google.com with ESMTPS id e8sm157796wiy.3.2012.05.03.07.27.09 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 03 May 2012 07:27:10 -0700 (PDT) From: "Roni Even" To: "'Johan Ludvig Nielsen \(johaniel\)'" , "'Paul Kyzivat'" References: <4F997E6B.7070501@alum.mit.edu><4F9B0D81.4040608@alum.mit.edu><4F9EC454.3060605@alum.mit.edu> <05DD269BD82AA549BC4B2619BBAC466A0109F228@XMB-AMS-206.cisco.com> <4FA15144.9030307@alum.mit.edu> <05DD269BD82AA549BC4B2619BBAC466A0109F407@XMB-AMS-206.cisco.com> In-Reply-To: <05DD269BD82AA549BC4B2619BBAC466A0109F407@XMB-AMS-206.cisco.com> Date: Thu, 3 May 2012 17:25:18 +0300 Message-ID: <4fa295be.0852b40a.771f.1804@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: Ac0od3X3UfwvQJL7TDa0MMR12dlCqwAjSbtgAAy7r3A= Content-Language: en-us Cc: 'CLUE' Subject: Re: [clue] ways of managing presentations in telepresence sessions X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 03 May 2012 14:27:14 -0000 Hi, See inline Roni > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Johan Ludvig Nielsen (johaniel) > Sent: Thursday, May 03, 2012 4:02 PM > To: Paul Kyzivat > Cc: CLUE > Subject: Re: [clue] ways of managing presentations in telepresence > sessions > > Sorry for being unclear. I am commenting on the implied option of > rendering presentation on a separate system, either on one or several > computers or a dedicated endpoint separate from the telepresence system > in the room. > > My main point is that all audio belonging to a conference and being > played back in a room must be controlled by or at least known to the > audio processing unit sending audio _from_ that room. This is to avoid > echo or multi-path problems. > > One example of such a problem is if a presentation in the form of a > movie with a soundtrack is played back on a computer separate from the > telepresence system in the room. The microphone system in the room will > pick up the sound from the computer's loudspeakers and happily transmit > that as voice into the conference. The presentation audio is then > delivered to other sites through two different paths with different > delays, one of them with poor quality. This is not a problem of the current protocols, you can send two audio streams in SIP and assign a different content attribute to each of them. The issue of the local echo of the movie sound to the people audio is a local system issue and not a standard issue. As for handling two audio streams this will require a definition like H.239 for this case in order to achieve interoperability. > > The other (and totally separate) point I am making is that with CLUE we > will have the ability to send presentation audio as a separate stream, > and that we are happy about that. Today locally input presentation > audio is most often mixed with the mic signal and sent in the main > audio stream (which can be stereo). There is no H.239 equivalent for > audio. Sending two separate audio is not a CLUE feature, it can be done by offering two audio RTP sessions for example. > > Regards > Johan > > > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: 2. mai 2012 17:23 > To: Johan Ludvig Nielsen (johaniel) > Cc: Stephen Botzko; CLUE > Subject: Re: [clue] ways of managing presentations in telepresence > sessions > > On 5/2/12 8:06 AM, Johan Ludvig Nielsen (johaniel) wrote: > > I just want to remind you all that presentation often means video > > _and_ audio, for instance a movie clip with a stereo soundtrack. > > Sometimes presentation means only audio. Hook up your favourite > device > > > and share a music clip or an interesting recording. > > > > Any presentation audio played back locally must be controlled by, or > > at least be exactly (in sample sync) known to, the local telepresence > > system controller. A totally separate endpoint for presentation will > > therefore cause some practical problems. > > > > By the way, one very useful effect of CLUE is the ability for > > receiving endpoints to distinguish between audio from live talking > > sources and presentations/recordings. > > I'm not sure I understand the point you are making. > Certainly it is true that a presentation may consist of audio and > video. > But its not just presentations that can contain paired audio and video. > When we have many audio and video captures, there could be several > pairs. > > RFC3388 provides a way (a=mid:ls) to indicate when lip sync is > required. > Do we need more than that? Should advertisements indicate desirable > audio/video pairings so that selection can take that into account? > > Thanks, > Paul > > > Johan > > > > *From:*clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On > Behalf > > > Of *Stephen Botzko > > *Sent:* 1. mai 2012 09:11 > > *To:* Paul Kyzivat > > *Cc:* CLUE > > *Subject:* Re: [clue] ways of managing presentations in telepresence > > sessions > > > > On Mon, Apr 30, 2012 at 12:56 PM, Paul Kyzivat > > wrote: > > > > On 4/28/12 1:18 PM, Stephen Botzko wrote: > > > > [sb] As I mentioned above, the existing solutions usually include a > > screen-scrape application, so you don't have to use a video cable. > > This is essentially the same as using Webex for presenting (but not > > remote control). > > > > How are these solutions connected? Does the captured application data > > go to the local room controller, or to an MCU in the middle of the TP > > session? Or something else? > > > > [sb] They are normally connected to the local room telepresence > system. > > Again, the people in the local room also need to see the > presentation, > > > so this is the most direct and also is the most bandwidth efficient > > approach. Another aspect is that the rooms can and are used purely > > locally (with no remote systems at all), and presentations also need > > to work in that situation. BTW I think adding requirements for > support > > > of multiple endpoints in the same room is an unwise path - this is > not > > > SPLICES, and we have enough to do already. I agree with folks who are > > saying it is out of scope[/sb] > > > > Also, even though Webex allows remote control, in my > > experience that feature is not used as much as simple > > presenting. I am > > not saying it has no value, just that the most common case I > see > > is a > > simple presentation. > > > > That is my experience as well. I wasn't thinking about the > > multi-user-control aspect. > > > > Supporting the video cable still has value, especially if you > > have guest > > presenter who does not have access to your local network. > Most > > of those > > presenters are expecting to use a projector, so they have the > cables > > with them. > > > > Surely. In this case, I presume the cable connects to the local > room > > controller. If there are multiple cable connectors (e.g. one at > each > > seat) do they show up as multiple presentation streams? Or is > there > > some sort of switch and floor control? If so, how does one manage > > the floor control? > > > > [sb] Today there is one presenter at a time. With multiple > cables, > > there is usually a button at each spot, and if you press it you > > become the presenter (most recent request wins is the policy). > > Normal social courtesies handle conflict, so there is no real > need > > for formal floor control. This happens even in ordinary webex > > conferences - if someone grabs the ball when they shouldn't have > it, > > people say something and it gets resolved. Similarly, if someone > > needs the ball. More precisely, the presenting video system holds > > the token for the room. With H.239, the MCU (if there is one) > grants > > it, using whatever policy it wants, and can revoke it at any > time. > > In point-to-point calls, the far end SHALL grant it upon request, > so > > in that case the turn-taking policy is mandated in the standard. > > Multiple presenters in the same room is up to the local room > policy > > - there is no standard, and in my opinion none is needed. The > token > > remains owned by the local video system, it is allowed to present > > whatever local source it wishes. [/sb] > > > > My answer on application sharing falling "out of favor" > related > > specifically to vendor support for standards-based > application > > sharing > > (T.120 in particular) - which I thought was responsive to > your > > original > > question. Perhaps I misunderstood it. Anyway there were > several > > reasons [and perhaps various viewpoints] on why T.120 was > dropped, > > though I think it is probably not a useful discussion for > this > > list. I > > know of no other standards-based protocol for application > sharing. > > > > I wasn't assuming there was, other than a pure video (and maybe > > audio) stream interface. There are other fora for that sort of > > thing, but its my impression that this is largely a world of > > proprietary and defacto standards. > > > > BTW, it is relatively common for web screen sharing to > co-exist > > with the > > videoconferencing presentation methods. For instance, you can > have a > > stand-alone webex conference, with someone sharing their > laptop > > screen > > for the video participants.[/sb] > > > > I have done this. But it was cumbersome. IIRC, getting the > sharing > > to be visible in the room I was in required using a video cable > in > > addition to using webex sharing. > > > > [sb]With our equipment you could use the cable if you wished, but it > > would not be required. Though generally speaking, people are used to > > using projectors for presenting. Video systems are providing > identical > > > interfaces, so they work the way people expect. For instance, in IETF > > interim meetings the Webex screen is always presented locally, > > frequently using a cable. The chairs may find that cumbersome, but > > they certainly come into the meeting expecting to do it anyway.[\sb] > > > > Of course that is still somewhat cumbersome, but presumably > it > will > > be improved over time. Its the UI for driving it that is > cumbersome, > > not the output. > > > > A key difference is that if the computer output is via video > cable > > into the local room controller, then that is probably > responsible > > for displaying it locally on a display in the room as well as > > sending it to the remote end. If the users connect their > computers > > directly to the MCU, then the capture will come to the room > just > > like anything else from the MCU. > > > > [sb]The standard model for videoconferencing presentations is > a > > token-controlled transmission. If you don't have the token, > you are > > receiving. The local equipment is always responsible for > display. > > Looping the presentation back through the MCU back to the > > originating > > site wastes bandwidth. > > > > I don't know if web conferencing solutions do this > differently > > or not. > > I've always assumed that when I grab the webex "ball" I stop > > receiving > > desktop images. Certainly there is no reason for the server > to > send > > them back to me.[/sb] > > > > > > Thanks, > > Paul > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From pkyzivat@alum.mit.edu Thu May 3 08:59:28 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E18E21F8634 for ; Thu, 3 May 2012 08:59:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.485 X-Spam-Level: X-Spam-Status: No, score=-2.485 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fM3cCyqegDAo for ; Thu, 3 May 2012 08:59:27 -0700 (PDT) Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [76.96.62.17]) by ietfa.amsl.com (Postfix) with ESMTP id F252221F8601 for ; Thu, 3 May 2012 08:59:26 -0700 (PDT) Received: from omta16.westchester.pa.mail.comcast.net ([76.96.62.88]) by qmta10.westchester.pa.mail.comcast.net with comcast id 5RE51j0061uE5Es5ATzJF2; Thu, 03 May 2012 15:59:18 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta16.westchester.pa.mail.comcast.net with comcast id 5TzT1j00Y07duvL3cTzTvn; Thu, 03 May 2012 15:59:27 +0000 Message-ID: <4FA2AB5D.7050205@alum.mit.edu> Date: Thu, 03 May 2012 11:59:25 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "Johan Ludvig Nielsen (johaniel)" References: <4F997E6B.7070501@alum.mit.edu><4F9B0D81.4040608@alum.mit.edu><4F9EC454.3060605@alum.mit.edu> <05DD269BD82AA549BC4B2619BBAC466A0109F228@XMB-AMS-206.cisco.com> <4FA15144.9030307@alum.mit.edu> <05DD269BD82AA549BC4B2619BBAC466A0109F407@XMB-AMS-206.cisco.com> In-Reply-To: <05DD269BD82AA549BC4B2619BBAC466A0109F407@XMB-AMS-206.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: CLUE Subject: Re: [clue] ways of managing presentations in telepresence sessions X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 03 May 2012 15:59:28 -0000 On 5/3/12 9:02 AM, Johan Ludvig Nielsen (johaniel) wrote: > Sorry for being unclear. I am commenting on the implied option of > rendering presentation on a separate system, either on one or several > computers or a dedicated endpoint separate from the telepresence system > in the room. > > My main point is that all audio belonging to a conference and being > played back in a room must be controlled by or at least known to the > audio processing unit sending audio _from_ that room. This is to avoid > echo or multi-path problems. > > One example of such a problem is if a presentation in the form of a > movie with a soundtrack is played back on a computer separate from the > telepresence system in the room. The microphone system in the room will > pick up the sound from the computer's loudspeakers and happily transmit > that as voice into the conference. The presentation audio is then > delivered to other sites through two different paths with different > delays, one of them with poor quality. OK, this is a good point. So a participant sitting in a TP room could connect his computer to the MCU for the TP session as an independent endpoint and receive and play out video captures without trouble. But if it receives and plays out audio there might be trouble. If it were just presentation audio, and it was played back to headphones it might be ok. But if played back via speakers it could be a problem. I suppose that is something that would have to be considered pilot error rather than a defect in CLUE. > The other (and totally separate) point I am making is that with CLUE we > will have the ability to send presentation audio as a separate stream, > and that we are happy about that. Today locally input presentation audio > is most often mixed with the mic signal and sent in the main audio > stream (which can be stereo). There is no H.239 equivalent for audio. So yes, we have that capability. Do we have sufficient description of it to make it fully usable? In particular, do we have enough so that, when selecting which capture scene entries and captures to receive, the recipient will be able to identify audio/video pairs so that they can be selected as a pair? Thanks, Paul > Regards > Johan > > > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: 2. mai 2012 17:23 > To: Johan Ludvig Nielsen (johaniel) > Cc: Stephen Botzko; CLUE > Subject: Re: [clue] ways of managing presentations in telepresence > sessions > > On 5/2/12 8:06 AM, Johan Ludvig Nielsen (johaniel) wrote: >> I just want to remind you all that presentation often means video >> _and_ audio, for instance a movie clip with a stereo soundtrack. >> Sometimes presentation means only audio. Hook up your favourite device > >> and share a music clip or an interesting recording. >> >> Any presentation audio played back locally must be controlled by, or >> at least be exactly (in sample sync) known to, the local telepresence >> system controller. A totally separate endpoint for presentation will >> therefore cause some practical problems. >> >> By the way, one very useful effect of CLUE is the ability for >> receiving endpoints to distinguish between audio from live talking >> sources and presentations/recordings. > > I'm not sure I understand the point you are making. > Certainly it is true that a presentation may consist of audio and video. > But its not just presentations that can contain paired audio and video. > When we have many audio and video captures, there could be several > pairs. > > RFC3388 provides a way (a=mid:ls) to indicate when lip sync is required. > Do we need more than that? Should advertisements indicate desirable > audio/video pairings so that selection can take that into account? > > Thanks, > Paul > >> Johan >> >> *From:*clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On Behalf > >> Of *Stephen Botzko >> *Sent:* 1. mai 2012 09:11 >> *To:* Paul Kyzivat >> *Cc:* CLUE >> *Subject:* Re: [clue] ways of managing presentations in telepresence >> sessions >> >> On Mon, Apr 30, 2012 at 12:56 PM, Paul Kyzivat> > wrote: >> >> On 4/28/12 1:18 PM, Stephen Botzko wrote: >> >> [sb] As I mentioned above, the existing solutions usually include a >> screen-scrape application, so you don't have to use a video cable. >> This is essentially the same as using Webex for presenting (but not >> remote control). >> >> How are these solutions connected? Does the captured application data >> go to the local room controller, or to an MCU in the middle of the TP >> session? Or something else? >> >> [sb] They are normally connected to the local room telepresence > system. >> Again, the people in the local room also need to see the presentation, > >> so this is the most direct and also is the most bandwidth efficient >> approach. Another aspect is that the rooms can and are used purely >> locally (with no remote systems at all), and presentations also need >> to work in that situation. BTW I think adding requirements for support > >> of multiple endpoints in the same room is an unwise path - this is not > >> SPLICES, and we have enough to do already. I agree with folks who are >> saying it is out of scope[/sb] >> >> Also, even though Webex allows remote control, in my >> experience that feature is not used as much as simple >> presenting. I am >> not saying it has no value, just that the most common case I > see >> is a >> simple presentation. >> >> That is my experience as well. I wasn't thinking about the >> multi-user-control aspect. >> >> Supporting the video cable still has value, especially if you >> have guest >> presenter who does not have access to your local network. Most >> of those >> presenters are expecting to use a projector, so they have the > cables >> with them. >> >> Surely. In this case, I presume the cable connects to the local > room >> controller. If there are multiple cable connectors (e.g. one at > each >> seat) do they show up as multiple presentation streams? Or is > there >> some sort of switch and floor control? If so, how does one manage >> the floor control? >> >> [sb] Today there is one presenter at a time. With multiple cables, >> there is usually a button at each spot, and if you press it you >> become the presenter (most recent request wins is the policy). >> Normal social courtesies handle conflict, so there is no real need >> for formal floor control. This happens even in ordinary webex >> conferences - if someone grabs the ball when they shouldn't have > it, >> people say something and it gets resolved. Similarly, if someone >> needs the ball. More precisely, the presenting video system holds >> the token for the room. With H.239, the MCU (if there is one) > grants >> it, using whatever policy it wants, and can revoke it at any time. >> In point-to-point calls, the far end SHALL grant it upon request, > so >> in that case the turn-taking policy is mandated in the standard. >> Multiple presenters in the same room is up to the local room > policy >> - there is no standard, and in my opinion none is needed. The > token >> remains owned by the local video system, it is allowed to present >> whatever local source it wishes. [/sb] >> >> My answer on application sharing falling "out of favor" > related >> specifically to vendor support for standards-based application >> sharing >> (T.120 in particular) - which I thought was responsive to your >> original >> question. Perhaps I misunderstood it. Anyway there were > several >> reasons [and perhaps various viewpoints] on why T.120 was > dropped, >> though I think it is probably not a useful discussion for this >> list. I >> know of no other standards-based protocol for application > sharing. >> >> I wasn't assuming there was, other than a pure video (and maybe >> audio) stream interface. There are other fora for that sort of >> thing, but its my impression that this is largely a world of >> proprietary and defacto standards. >> >> BTW, it is relatively common for web screen sharing to > co-exist >> with the >> videoconferencing presentation methods. For instance, you can > have a >> stand-alone webex conference, with someone sharing their > laptop >> screen >> for the video participants.[/sb] >> >> I have done this. But it was cumbersome. IIRC, getting the sharing >> to be visible in the room I was in required using a video cable in >> addition to using webex sharing. >> >> [sb]With our equipment you could use the cable if you wished, but it >> would not be required. Though generally speaking, people are used to >> using projectors for presenting. Video systems are providing identical > >> interfaces, so they work the way people expect. For instance, in IETF >> interim meetings the Webex screen is always presented locally, >> frequently using a cable. The chairs may find that cumbersome, but >> they certainly come into the meeting expecting to do it anyway.[\sb] >> >> Of course that is still somewhat cumbersome, but presumably it > will >> be improved over time. Its the UI for driving it that is > cumbersome, >> not the output. >> >> A key difference is that if the computer output is via video > cable >> into the local room controller, then that is probably > responsible >> for displaying it locally on a display in the room as well as >> sending it to the remote end. If the users connect their > computers >> directly to the MCU, then the capture will come to the room > just >> like anything else from the MCU. >> >> [sb]The standard model for videoconferencing presentations is > a >> token-controlled transmission. If you don't have the token, > you are >> receiving. The local equipment is always responsible for > display. >> Looping the presentation back through the MCU back to the >> originating >> site wastes bandwidth. >> >> I don't know if web conferencing solutions do this differently >> or not. >> I've always assumed that when I grab the webex "ball" I stop >> receiving >> desktop images. Certainly there is no reason for the server to > send >> them back to me.[/sb] >> >> >> Thanks, >> Paul >> > > From br@brianrosen.net Thu May 3 09:18:55 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B99821F8636 for ; Thu, 3 May 2012 09:18:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.55 X-Spam-Level: X-Spam-Status: No, score=-102.55 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CjJeEywmUHkz for ; Thu, 3 May 2012 09:18:54 -0700 (PDT) Received: from barmail4.idig.net (barmail4.idig.net [64.34.111.235]) by ietfa.amsl.com (Postfix) with ESMTP id 4603721F8625 for ; Thu, 3 May 2012 09:18:54 -0700 (PDT) X-ASG-Debug-ID: 1336061932-04d03579c8b4550001-dOUo1C Received: from wwh1.winweblinux.com (wwh1.winweblinux.com [76.74.186.184]) by barmail4.idig.net with ESMTP id RJCcWOF2Q8xPYyuF; Thu, 03 May 2012 09:18:52 -0700 (PDT) X-Barracuda-Envelope-From: br@brianrosen.net X-Barracuda-Apparent-Source-IP: 76.74.186.184 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=[156.154.4.13]) by wwh1.winweblinux.com with esmtpa (Exim 4.69) (envelope-from ) id 1SPyk0-000nhW-1G; Thu, 03 May 2012 09:18:52 -0700 Mime-Version: 1.0 (Apple Message framework v1257) X-ASG-Orig-Subj: Re: [clue] ways of managing presentations in telepresence sessions Content-Type: text/plain; charset=us-ascii From: Brian Rosen In-Reply-To: <4fa295be.0852b40a.771f.1804@mx.google.com> Date: Thu, 3 May 2012 12:18:48 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F997E6B.7070501@alum.mit.edu><4F9B0D81.4040608@alum.mit.edu><4F9EC454.3060605@alum.mit.edu> <05DD269BD82AA549BC4B2619BBAC466A0109F228@XMB-AMS-206.cisco.com> <4FA15144.9030307@alum.mit.edu> <05DD269BD82AA549BC4B2619BBAC466A0109F407@XMB-AMS-206.cisco.com> <4fa295be.0852b40a.771f.1804@mx.google.com> To: Roni Even X-Mailer: Apple Mail (2.1257) X-Barracuda-Connect: wwh1.winweblinux.com[76.74.186.184] X-Barracuda-Start-Time: 1336061932 X-Barracuda-URL: http://64.34.111.235:8000/cgi-mod/mark.cgi X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.5 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.95884 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Cc: 'CLUE' , "'Johan Ludvig Nielsen \(johaniel\)'" Subject: Re: [clue] ways of managing presentations in telepresence sessions X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 03 May 2012 16:18:55 -0000 I go back to what I see is the fundamental issue: You have two separate systems from two vendors in one room. They = interact in a way that is important to other rooms. We don't have = mechanisms to represent this. Brian On May 3, 2012, at 10:25 AM, Roni Even wrote: > Hi, > See inline > Roni >=20 >> -----Original Message----- >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf = Of >> Johan Ludvig Nielsen (johaniel) >> Sent: Thursday, May 03, 2012 4:02 PM >> To: Paul Kyzivat >> Cc: CLUE >> Subject: Re: [clue] ways of managing presentations in telepresence >> sessions >>=20 >> Sorry for being unclear. I am commenting on the implied option of >> rendering presentation on a separate system, either on one or several >> computers or a dedicated endpoint separate from the telepresence = system >> in the room. >>=20 >> My main point is that all audio belonging to a conference and being >> played back in a room must be controlled by or at least known to the >> audio processing unit sending audio _from_ that room. This is to = avoid >> echo or multi-path problems. >>=20 >> One example of such a problem is if a presentation in the form of a >> movie with a soundtrack is played back on a computer separate from = the >> telepresence system in the room. The microphone system in the room = will >> pick up the sound from the computer's loudspeakers and happily = transmit >> that as voice into the conference. The presentation audio is then >> delivered to other sites through two different paths with different >> delays, one of them with poor quality. >=20 > This is not a problem of the current protocols, you can send two audio > streams in SIP and assign a different content attribute to each of = them. The > issue of the local echo of the movie sound to the people audio is a = local > system issue and not a standard issue. As for handling two audio = streams > this will require a definition like H.239 for this case in order to = achieve > interoperability. >>=20 >> The other (and totally separate) point I am making is that with CLUE = we >> will have the ability to send presentation audio as a separate = stream, >> and that we are happy about that. Today locally input presentation >> audio is most often mixed with the mic signal and sent in the main >> audio stream (which can be stereo). There is no H.239 equivalent for >> audio. >=20 > Sending two separate audio is not a CLUE feature, it can be done by = offering > two audio RTP sessions for example. >=20 >>=20 >> Regards >> Johan >>=20 >>=20 >>=20 >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >> Sent: 2. mai 2012 17:23 >> To: Johan Ludvig Nielsen (johaniel) >> Cc: Stephen Botzko; CLUE >> Subject: Re: [clue] ways of managing presentations in telepresence >> sessions >>=20 >> On 5/2/12 8:06 AM, Johan Ludvig Nielsen (johaniel) wrote: >>> I just want to remind you all that presentation often means video >>> _and_ audio, for instance a movie clip with a stereo soundtrack. >>> Sometimes presentation means only audio. Hook up your favourite >> device >>=20 >>> and share a music clip or an interesting recording. >>>=20 >>> Any presentation audio played back locally must be controlled by, or >>> at least be exactly (in sample sync) known to, the local = telepresence >>> system controller. A totally separate endpoint for presentation will >>> therefore cause some practical problems. >>>=20 >>> By the way, one very useful effect of CLUE is the ability for >>> receiving endpoints to distinguish between audio from live talking >>> sources and presentations/recordings. >>=20 >> I'm not sure I understand the point you are making. >> Certainly it is true that a presentation may consist of audio and >> video. >> But its not just presentations that can contain paired audio and = video. >> When we have many audio and video captures, there could be several >> pairs. >>=20 >> RFC3388 provides a way (a=3Dmid:ls) to indicate when lip sync is >> required. >> Do we need more than that? Should advertisements indicate desirable >> audio/video pairings so that selection can take that into account? >>=20 >> Thanks, >> Paul >>=20 >>> Johan >>>=20 >>> *From:*clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On >> Behalf >>=20 >>> Of *Stephen Botzko >>> *Sent:* 1. mai 2012 09:11 >>> *To:* Paul Kyzivat >>> *Cc:* CLUE >>> *Subject:* Re: [clue] ways of managing presentations in telepresence >>> sessions >>>=20 >>> On Mon, Apr 30, 2012 at 12:56 PM, Paul Kyzivat = >> > wrote: >>>=20 >>> On 4/28/12 1:18 PM, Stephen Botzko wrote: >>>=20 >>> [sb] As I mentioned above, the existing solutions usually include a >>> screen-scrape application, so you don't have to use a video cable. >>> This is essentially the same as using Webex for presenting (but not >>> remote control). >>>=20 >>> How are these solutions connected? Does the captured application = data >>> go to the local room controller, or to an MCU in the middle of the = TP >>> session? Or something else? >>>=20 >>> [sb] They are normally connected to the local room telepresence >> system. >>> Again, the people in the local room also need to see the >> presentation, >>=20 >>> so this is the most direct and also is the most bandwidth efficient >>> approach. Another aspect is that the rooms can and are used purely >>> locally (with no remote systems at all), and presentations also need >>> to work in that situation. BTW I think adding requirements for >> support >>=20 >>> of multiple endpoints in the same room is an unwise path - this is >> not >>=20 >>> SPLICES, and we have enough to do already. I agree with folks who = are >>> saying it is out of scope[/sb] >>>=20 >>> Also, even though Webex allows remote control, in my >>> experience that feature is not used as much as simple >>> presenting. I am >>> not saying it has no value, just that the most common case I >> see >>> is a >>> simple presentation. >>>=20 >>> That is my experience as well. I wasn't thinking about the >>> multi-user-control aspect. >>>=20 >>> Supporting the video cable still has value, especially if you >>> have guest >>> presenter who does not have access to your local network. >> Most >>> of those >>> presenters are expecting to use a projector, so they have the >> cables >>> with them. >>>=20 >>> Surely. In this case, I presume the cable connects to the local >> room >>> controller. If there are multiple cable connectors (e.g. one at >> each >>> seat) do they show up as multiple presentation streams? Or is >> there >>> some sort of switch and floor control? If so, how does one manage >>> the floor control? >>>=20 >>> [sb] Today there is one presenter at a time. With multiple >> cables, >>> there is usually a button at each spot, and if you press it you >>> become the presenter (most recent request wins is the policy). >>> Normal social courtesies handle conflict, so there is no real >> need >>> for formal floor control. This happens even in ordinary webex >>> conferences - if someone grabs the ball when they shouldn't have >> it, >>> people say something and it gets resolved. Similarly, if someone >>> needs the ball. More precisely, the presenting video system holds >>> the token for the room. With H.239, the MCU (if there is one) >> grants >>> it, using whatever policy it wants, and can revoke it at any >> time. >>> In point-to-point calls, the far end SHALL grant it upon request, >> so >>> in that case the turn-taking policy is mandated in the standard. >>> Multiple presenters in the same room is up to the local room >> policy >>> - there is no standard, and in my opinion none is needed. The >> token >>> remains owned by the local video system, it is allowed to present >>> whatever local source it wishes. [/sb] >>>=20 >>> My answer on application sharing falling "out of favor" >> related >>> specifically to vendor support for standards-based >> application >>> sharing >>> (T.120 in particular) - which I thought was responsive to >> your >>> original >>> question. Perhaps I misunderstood it. Anyway there were >> several >>> reasons [and perhaps various viewpoints] on why T.120 was >> dropped, >>> though I think it is probably not a useful discussion for >> this >>> list. I >>> know of no other standards-based protocol for application >> sharing. >>>=20 >>> I wasn't assuming there was, other than a pure video (and maybe >>> audio) stream interface. There are other fora for that sort of >>> thing, but its my impression that this is largely a world of >>> proprietary and defacto standards. >>>=20 >>> BTW, it is relatively common for web screen sharing to >> co-exist >>> with the >>> videoconferencing presentation methods. For instance, you can >> have a >>> stand-alone webex conference, with someone sharing their >> laptop >>> screen >>> for the video participants.[/sb] >>>=20 >>> I have done this. But it was cumbersome. IIRC, getting the >> sharing >>> to be visible in the room I was in required using a video cable >> in >>> addition to using webex sharing. >>>=20 >>> [sb]With our equipment you could use the cable if you wished, but it >>> would not be required. Though generally speaking, people are used to >>> using projectors for presenting. Video systems are providing >> identical >>=20 >>> interfaces, so they work the way people expect. For instance, in = IETF >>> interim meetings the Webex screen is always presented locally, >>> frequently using a cable. The chairs may find that cumbersome, but >>> they certainly come into the meeting expecting to do it anyway.[\sb] >>>=20 >>> Of course that is still somewhat cumbersome, but presumably >> it >> will >>> be improved over time. Its the UI for driving it that is >> cumbersome, >>> not the output. >>>=20 >>> A key difference is that if the computer output is via video >> cable >>> into the local room controller, then that is probably >> responsible >>> for displaying it locally on a display in the room as well as >>> sending it to the remote end. If the users connect their >> computers >>> directly to the MCU, then the capture will come to the room >> just >>> like anything else from the MCU. >>>=20 >>> [sb]The standard model for videoconferencing presentations is >> a >>> token-controlled transmission. If you don't have the token, >> you are >>> receiving. The local equipment is always responsible for >> display. >>> Looping the presentation back through the MCU back to the >>> originating >>> site wastes bandwidth. >>>=20 >>> I don't know if web conferencing solutions do this >> differently >>> or not. >>> I've always assumed that when I grab the webex "ball" I stop >>> receiving >>> desktop images. Certainly there is no reason for the server >> to >> send >>> them back to me.[/sb] >>>=20 >>>=20 >>> Thanks, >>> Paul >>>=20 >>=20 >> _______________________________________________ >> 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 From stephen.botzko@gmail.com Thu May 3 13:40:15 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4938621F85A1 for ; Thu, 3 May 2012 13:40:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.339 X-Spam-Level: X-Spam-Status: No, score=-3.339 tagged_above=-999 required=5 tests=[AWL=0.259, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W-pilThHu1oi for ; Thu, 3 May 2012 13:40:13 -0700 (PDT) Received: from mail-pz0-f52.google.com (mail-pz0-f52.google.com [209.85.210.52]) by ietfa.amsl.com (Postfix) with ESMTP id 5DFAB21F86A3 for ; Thu, 3 May 2012 13:40:13 -0700 (PDT) Received: by dadz9 with SMTP id z9so2931944dad.39 for ; Thu, 03 May 2012 13:40:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=EQE1r0ODmMkka1OfLNPeH30ediO559xjbn9je9qA75I=; b=ZlT9ZmZpPqomVk8iYM5zlcW35t2YA+pPIvcCofCPlcQbjVBMcRRPVgX+q+q4JKgBZ/ kQCLoKvNQUxjmlj3TMOE+WaWPNae5Hpbd66fGHJKKbRjfc1DMKsF/85mQ3lUZs6B3KIm B07Y12eQ4WhNsmfV/2EIgyZzdK9fpLsEW+5OkjeXw9hZeFpN+W7HFxQ/SKeaUlPjUmac lgkvTYHYSWfUI8jo7T4d5vOgE9tIoHsPoBmqi54AUBOgTd6QceGfirHHpkOdF/I8BtgF PbSkijqQtxCTtj33KaBg6a/3dWGek50TUS9kCdaSFy4jCMSVjo3NTSDsNyuBAMQzA30U iM3w== MIME-Version: 1.0 Received: by 10.68.221.74 with SMTP id qc10mr11225359pbc.80.1336077613041; Thu, 03 May 2012 13:40:13 -0700 (PDT) Received: by 10.68.239.228 with HTTP; Thu, 3 May 2012 13:40:12 -0700 (PDT) In-Reply-To: References: <4F997E6B.7070501@alum.mit.edu> <4F9B0D81.4040608@alum.mit.edu> <4F9EC454.3060605@alum.mit.edu> <05DD269BD82AA549BC4B2619BBAC466A0109F228@XMB-AMS-206.cisco.com> <4FA15144.9030307@alum.mit.edu> <05DD269BD82AA549BC4B2619BBAC466A0109F407@XMB-AMS-206.cisco.com> <4fa295be.0852b40a.771f.1804@mx.google.com> Date: Thu, 3 May 2012 22:40:12 +0200 Message-ID: From: Stephen Botzko To: Brian Rosen Content-Type: multipart/alternative; boundary=e89a8ff2432b8487b004bf27cfe4 Cc: CLUE , "Johan Ludvig Nielsen \(johaniel\)" Subject: Re: [clue] ways of managing presentations in telepresence sessions X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 03 May 2012 20:40:15 -0000 --e89a8ff2432b8487b004bf27cfe4 Content-Type: text/plain; charset=ISO-8859-1 I have two separate speakerphones from two vendors in one room calling into the same audio conference. They interact in a way that utterly fails to deliver usable audio to phones in other locations. We don't have mechanisms in SIP to represent this or prevent the bad behaviour. This is a problem for the IETF because???? Stephen Botzko On Thu, May 3, 2012 at 6:18 PM, Brian Rosen wrote: > I go back to what I see is the fundamental issue: > > You have two separate systems from two vendors in one room. They interact > in a way that is important to other rooms. We don't have mechanisms to > represent this. > > Brian > > On May 3, 2012, at 10:25 AM, Roni Even wrote: > > > Hi, > > See inline > > Roni > > > >> -----Original Message----- > >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > >> Johan Ludvig Nielsen (johaniel) > >> Sent: Thursday, May 03, 2012 4:02 PM > >> To: Paul Kyzivat > >> Cc: CLUE > >> Subject: Re: [clue] ways of managing presentations in telepresence > >> sessions > >> > >> Sorry for being unclear. I am commenting on the implied option of > >> rendering presentation on a separate system, either on one or several > >> computers or a dedicated endpoint separate from the telepresence system > >> in the room. > >> > >> My main point is that all audio belonging to a conference and being > >> played back in a room must be controlled by or at least known to the > >> audio processing unit sending audio _from_ that room. This is to avoid > >> echo or multi-path problems. > >> > >> One example of such a problem is if a presentation in the form of a > >> movie with a soundtrack is played back on a computer separate from the > >> telepresence system in the room. The microphone system in the room will > >> pick up the sound from the computer's loudspeakers and happily transmit > >> that as voice into the conference. The presentation audio is then > >> delivered to other sites through two different paths with different > >> delays, one of them with poor quality. > > > > This is not a problem of the current protocols, you can send two audio > > streams in SIP and assign a different content attribute to each of them. > The > > issue of the local echo of the movie sound to the people audio is a local > > system issue and not a standard issue. As for handling two audio streams > > this will require a definition like H.239 for this case in order to > achieve > > interoperability. > >> > >> The other (and totally separate) point I am making is that with CLUE we > >> will have the ability to send presentation audio as a separate stream, > >> and that we are happy about that. Today locally input presentation > >> audio is most often mixed with the mic signal and sent in the main > >> audio stream (which can be stereo). There is no H.239 equivalent for > >> audio. > > > > Sending two separate audio is not a CLUE feature, it can be done by > offering > > two audio RTP sessions for example. > > > >> > >> Regards > >> Johan > >> > >> > >> > >> -----Original Message----- > >> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > >> Sent: 2. mai 2012 17:23 > >> To: Johan Ludvig Nielsen (johaniel) > >> Cc: Stephen Botzko; CLUE > >> Subject: Re: [clue] ways of managing presentations in telepresence > >> sessions > >> > >> On 5/2/12 8:06 AM, Johan Ludvig Nielsen (johaniel) wrote: > >>> I just want to remind you all that presentation often means video > >>> _and_ audio, for instance a movie clip with a stereo soundtrack. > >>> Sometimes presentation means only audio. Hook up your favourite > >> device > >> > >>> and share a music clip or an interesting recording. > >>> > >>> Any presentation audio played back locally must be controlled by, or > >>> at least be exactly (in sample sync) known to, the local telepresence > >>> system controller. A totally separate endpoint for presentation will > >>> therefore cause some practical problems. > >>> > >>> By the way, one very useful effect of CLUE is the ability for > >>> receiving endpoints to distinguish between audio from live talking > >>> sources and presentations/recordings. > >> > >> I'm not sure I understand the point you are making. > >> Certainly it is true that a presentation may consist of audio and > >> video. > >> But its not just presentations that can contain paired audio and video. > >> When we have many audio and video captures, there could be several > >> pairs. > >> > >> RFC3388 provides a way (a=mid:ls) to indicate when lip sync is > >> required. > >> Do we need more than that? Should advertisements indicate desirable > >> audio/video pairings so that selection can take that into account? > >> > >> Thanks, > >> Paul > >> > >>> Johan > >>> > >>> *From:*clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On > >> Behalf > >> > >>> Of *Stephen Botzko > >>> *Sent:* 1. mai 2012 09:11 > >>> *To:* Paul Kyzivat > >>> *Cc:* CLUE > >>> *Subject:* Re: [clue] ways of managing presentations in telepresence > >>> sessions > >>> > >>> On Mon, Apr 30, 2012 at 12:56 PM, Paul Kyzivat >>> > wrote: > >>> > >>> On 4/28/12 1:18 PM, Stephen Botzko wrote: > >>> > >>> [sb] As I mentioned above, the existing solutions usually include a > >>> screen-scrape application, so you don't have to use a video cable. > >>> This is essentially the same as using Webex for presenting (but not > >>> remote control). > >>> > >>> How are these solutions connected? Does the captured application data > >>> go to the local room controller, or to an MCU in the middle of the TP > >>> session? Or something else? > >>> > >>> [sb] They are normally connected to the local room telepresence > >> system. > >>> Again, the people in the local room also need to see the > >> presentation, > >> > >>> so this is the most direct and also is the most bandwidth efficient > >>> approach. Another aspect is that the rooms can and are used purely > >>> locally (with no remote systems at all), and presentations also need > >>> to work in that situation. BTW I think adding requirements for > >> support > >> > >>> of multiple endpoints in the same room is an unwise path - this is > >> not > >> > >>> SPLICES, and we have enough to do already. I agree with folks who are > >>> saying it is out of scope[/sb] > >>> > >>> Also, even though Webex allows remote control, in my > >>> experience that feature is not used as much as simple > >>> presenting. I am > >>> not saying it has no value, just that the most common case I > >> see > >>> is a > >>> simple presentation. > >>> > >>> That is my experience as well. I wasn't thinking about the > >>> multi-user-control aspect. > >>> > >>> Supporting the video cable still has value, especially if you > >>> have guest > >>> presenter who does not have access to your local network. > >> Most > >>> of those > >>> presenters are expecting to use a projector, so they have the > >> cables > >>> with them. > >>> > >>> Surely. In this case, I presume the cable connects to the local > >> room > >>> controller. If there are multiple cable connectors (e.g. one at > >> each > >>> seat) do they show up as multiple presentation streams? Or is > >> there > >>> some sort of switch and floor control? If so, how does one manage > >>> the floor control? > >>> > >>> [sb] Today there is one presenter at a time. With multiple > >> cables, > >>> there is usually a button at each spot, and if you press it you > >>> become the presenter (most recent request wins is the policy). > >>> Normal social courtesies handle conflict, so there is no real > >> need > >>> for formal floor control. This happens even in ordinary webex > >>> conferences - if someone grabs the ball when they shouldn't have > >> it, > >>> people say something and it gets resolved. Similarly, if someone > >>> needs the ball. More precisely, the presenting video system holds > >>> the token for the room. With H.239, the MCU (if there is one) > >> grants > >>> it, using whatever policy it wants, and can revoke it at any > >> time. > >>> In point-to-point calls, the far end SHALL grant it upon request, > >> so > >>> in that case the turn-taking policy is mandated in the standard. > >>> Multiple presenters in the same room is up to the local room > >> policy > >>> - there is no standard, and in my opinion none is needed. The > >> token > >>> remains owned by the local video system, it is allowed to present > >>> whatever local source it wishes. [/sb] > >>> > >>> My answer on application sharing falling "out of favor" > >> related > >>> specifically to vendor support for standards-based > >> application > >>> sharing > >>> (T.120 in particular) - which I thought was responsive to > >> your > >>> original > >>> question. Perhaps I misunderstood it. Anyway there were > >> several > >>> reasons [and perhaps various viewpoints] on why T.120 was > >> dropped, > >>> though I think it is probably not a useful discussion for > >> this > >>> list. I > >>> know of no other standards-based protocol for application > >> sharing. > >>> > >>> I wasn't assuming there was, other than a pure video (and maybe > >>> audio) stream interface. There are other fora for that sort of > >>> thing, but its my impression that this is largely a world of > >>> proprietary and defacto standards. > >>> > >>> BTW, it is relatively common for web screen sharing to > >> co-exist > >>> with the > >>> videoconferencing presentation methods. For instance, you can > >> have a > >>> stand-alone webex conference, with someone sharing their > >> laptop > >>> screen > >>> for the video participants.[/sb] > >>> > >>> I have done this. But it was cumbersome. IIRC, getting the > >> sharing > >>> to be visible in the room I was in required using a video cable > >> in > >>> addition to using webex sharing. > >>> > >>> [sb]With our equipment you could use the cable if you wished, but it > >>> would not be required. Though generally speaking, people are used to > >>> using projectors for presenting. Video systems are providing > >> identical > >> > >>> interfaces, so they work the way people expect. For instance, in IETF > >>> interim meetings the Webex screen is always presented locally, > >>> frequently using a cable. The chairs may find that cumbersome, but > >>> they certainly come into the meeting expecting to do it anyway.[\sb] > >>> > >>> Of course that is still somewhat cumbersome, but presumably > >> it > >> will > >>> be improved over time. Its the UI for driving it that is > >> cumbersome, > >>> not the output. > >>> > >>> A key difference is that if the computer output is via video > >> cable > >>> into the local room controller, then that is probably > >> responsible > >>> for displaying it locally on a display in the room as well as > >>> sending it to the remote end. If the users connect their > >> computers > >>> directly to the MCU, then the capture will come to the room > >> just > >>> like anything else from the MCU. > >>> > >>> [sb]The standard model for videoconferencing presentations is > >> a > >>> token-controlled transmission. If you don't have the token, > >> you are > >>> receiving. The local equipment is always responsible for > >> display. > >>> Looping the presentation back through the MCU back to the > >>> originating > >>> site wastes bandwidth. > >>> > >>> I don't know if web conferencing solutions do this > >> differently > >>> or not. > >>> I've always assumed that when I grab the webex "ball" I stop > >>> receiving > >>> desktop images. Certainly there is no reason for the server > >> to > >> send > >>> them back to me.[/sb] > >>> > >>> > >>> Thanks, > >>> Paul > >>> > >> > >> _______________________________________________ > >> clue mailing list > >> clue@ietf.org > >> https://www.ietf.org/mailman/listinfo/clue > > > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > --e89a8ff2432b8487b004bf27cfe4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I have two separate speakerphones from two vendors in one room calling into= the same audio conference.=A0 They interact in a way that utterly fails to= deliver usable audio to phones in other locations.=A0 We don't have me= chanisms in SIP to represent this or prevent the bad behaviour.=A0

This is a problem for the IETF because????

Stephen Botzko
On Thu, May 3, 2012 at 6:18 PM, Brian Rosen <b= r@brianrosen.net> wrote:
I go back to what I see is the fundamental i= ssue:

You have two separate systems from two vendors in one room. =A0They interac= t in a way that is important to other rooms. =A0We don't have mechanism= s to represent this.

Brian

On May 3, 2012, at 10:25 AM, Roni Even wrote:

> Hi,
> See inline
> Roni
>
>> -----Original Message-----
>> From: clue-bounces@ietf.o= rg [mailto:clue-bounces@ietf.o= rg] On Behalf Of
>> Johan Ludvig Nielsen (johaniel)
>> Sent: Thursday, May 03, 2012 4:02 PM
>> To: Paul Kyzivat
>> Cc: CLUE
>> Subject: Re: [clue] ways of managing presentations in telepresence=
>> sessions
>>
>> Sorry for being unclear. I am commenting on the implied option of<= br> >> rendering presentation on a separate system, either on one or seve= ral
>> computers or a dedicated endpoint separate from the telepresence s= ystem
>> in the room.
>>
>> My main point is that all audio belonging to a conference and bein= g
>> played back in a room must be controlled by or at least known to t= he
>> audio processing unit sending audio _from_ that room. This is to a= void
>> echo or multi-path problems.
>>
>> One example of such a problem is if a presentation in the form of = a
>> movie with a soundtrack is played back on a computer separate from= the
>> telepresence system in the room. The microphone system in the room= will
>> pick up the sound from the computer's loudspeakers and happily= transmit
>> that as voice into the conference. The presentation audio is then<= br> >> delivered to other sites through two different paths with differen= t
>> delays, one of them with poor quality.
>
> This is not a problem of the current protocols, you can send two audio=
> streams in SIP and assign a different content attribute to each of the= m. The
> issue of the local echo of the movie sound to the people audio is a lo= cal
> system issue and not a standard issue. As for handling two audio strea= ms
> this will require a definition like H.239 for this case in order to ac= hieve
> interoperability.
>>
>> The other (and totally separate) point I am making is that with CL= UE we
>> will have the ability to send presentation audio as a separate str= eam,
>> and that we are happy about that. Today locally input presentation=
>> audio is most often mixed with the mic signal and sent in the main=
>> audio stream (which can be stereo). There is no H.239 equivalent f= or
>> audio.
>
> Sending two separate audio is not a CLUE feature, it can be done by of= fering
> two audio RTP sessions for example.
>
>>
>> Regards
>> Johan
>>
>>
>>
>> -----Original Message-----
>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]
>> Sent: 2. mai 2012 17:23
>> To: Johan Ludvig Nielsen (johaniel)
>> Cc: Stephen Botzko; CLUE
>> Subject: Re: [clue] ways of managing presentations in telepresence=
>> sessions
>>
>> On 5/2/12 8:06 AM, Johan Ludvig Nielsen (johaniel) wrote:
>>> I just want to remind you all that presentation often means vi= deo
>>> _and_ audio, for instance a movie clip with a stereo soundtrac= k.
>>> Sometimes presentation means only audio. Hook up your favourit= e
>> device
>>
>>> and share a music clip or an interesting recording.
>>>
>>> Any presentation audio played back locally must be controlled = by, or
>>> at least be exactly (in sample sync) known to, the local telep= resence
>>> system controller. A totally separate endpoint for presentatio= n will
>>> therefore cause some practical problems.
>>>
>>> By the way, one very useful effect of CLUE is the ability for<= br> >>> receiving endpoints to distinguish between audio from live tal= king
>>> sources and presentations/recordings.
>>
>> I'm not sure I understand the point you are making.
>> Certainly it is true that a presentation may consist of audio and<= br> >> video.
>> But its not just presentations that can contain paired audio and v= ideo.
>> When we have many audio and video captures, there could be several=
>> pairs.
>>
>> RFC3388 provides a way (a=3Dmid:ls) to indicate when lip sync is >> required.
>> Do we need more than that? Should advertisements indicate desirabl= e
>> audio/video pairings so that selection can take that into account?=
>>
>> =A0 =A0 =A0Thanks,
>> =A0 =A0 =A0Paul
>>
>>> Johan
>>>
>>> *From:*clue-bounces@i= etf.org [mailto:clue-bounces@i= etf.org] *On
>> Behalf
>>
>>> Of *Stephen Botzko
>>> *Sent:* 1. mai 2012 09:11
>>> *To:* Paul Kyzivat
>>> *Cc:* CLUE
>>> *Subject:* Re: [clue] ways of managing presentations in telepr= esence
>>> sessions
>>>
>>> On Mon, Apr 30, 2012 at 12:56 PM, Paul Kyzivat <pkyzivat@alum.mit.edu
>>> <mailto:pkyzivat@a= lum.mit.edu>> wrote:
>>>
>>> On 4/28/12 1:18 PM, Stephen Botzko wrote:
>>>
>>> [sb] As I mentioned above, the existing solutions usually incl= ude a
>>> screen-scrape application, so you don't have to use a vide= o cable.
>>> This is essentially the same as using Webex for presenting (bu= t not
>>> remote control).
>>>
>>> How are these solutions connected? Does the captured applicati= on data
>>> go to the local room controller, or to an MCU in the middle of= the TP
>>> session? Or something else?
>>>
>>> [sb] They are normally connected to the local room telepresenc= e
>> system.
>>> Again, the people in the local room also need to see the
>> presentation,
>>
>>> so this is the most direct and also is the most bandwidth effi= cient
>>> approach. Another aspect is that the rooms can and are used pu= rely
>>> locally (with no remote systems at all), and presentations als= o need
>>> to work in that situation. BTW I think adding requirements for=
>> support
>>
>>> of multiple endpoints in the same room is an unwise path - thi= s is
>> not
>>
>>> SPLICES, and we have enough to do already. I agree with folks = who are
>>> saying it is out of scope[/sb]
>>>
>>> =A0 =A0 =A0 =A0Also, even though Webex allows remote control, = in my
>>> =A0 =A0 =A0 =A0experience that feature is not used as much as = simple
>>> =A0 =A0 =A0 =A0presenting. I am
>>> =A0 =A0 =A0 =A0not saying it has no value, just that the most = common case I
>> see
>>> =A0 =A0 =A0 =A0is a
>>> =A0 =A0 =A0 =A0simple presentation.
>>>
>>> =A0 =A0That is my experience as well. I wasn't thinking ab= out the
>>> =A0 =A0multi-user-control aspect.
>>>
>>> =A0 =A0 =A0 =A0Supporting the video cable still has value, esp= ecially if you
>>> =A0 =A0 =A0 =A0have guest
>>> =A0 =A0 =A0 =A0presenter who does not have access to your loca= l network.
>> Most
>>> =A0 =A0 =A0 =A0of those
>>> =A0 =A0 =A0 =A0presenters are expecting to use a projector, so= they have the
>> cables
>>> =A0 =A0 =A0 =A0with them.
>>>
>>> =A0 =A0Surely. In this case, I presume the cable connects to t= he local
>> room
>>> =A0 =A0controller. If there are multiple cable connectors (e.g= . one at
>> each
>>> =A0 =A0seat) do they show up as multiple presentation streams?= Or is
>> there
>>> =A0 =A0some sort of switch and floor control? If so, how does = one manage
>>> =A0 =A0the floor control?
>>>
>>> =A0 =A0[sb] Today there is one presenter at a time. With multi= ple
>> cables,
>>> =A0 =A0there is usually a button at each spot, and if you pres= s it you
>>> =A0 =A0become the presenter (most recent request wins is the p= olicy).
>>> =A0 =A0Normal social courtesies handle conflict, so there is n= o real
>> need
>>> =A0 =A0for formal floor control. This happens even in ordinary= webex
>>> =A0 =A0conferences - if someone grabs the ball when they shoul= dn't have
>> it,
>>> =A0 =A0people say something and it gets resolved. Similarly, i= f someone
>>> =A0 =A0needs the ball. More precisely, the presenting video sy= stem holds
>>> =A0 =A0the token for the room. With H.239, the MCU (if there i= s one)
>> grants
>>> =A0 =A0it, using whatever policy it wants, and can revoke it a= t any
>> time.
>>> =A0 =A0In point-to-point calls, the far end SHALL grant it upo= n request,
>> so
>>> =A0 =A0in that case the turn-taking policy is mandated in the = standard.
>>> =A0 =A0Multiple presenters in the same room is up to the local= room
>> policy
>>> =A0 =A0- there is no standard, and in my opinion none is neede= d. The
>> token
>>> =A0 =A0remains owned by the local video system, it is allowed = to present
>>> =A0 =A0whatever local source it wishes. [/sb]
>>>
>>> =A0 =A0 =A0 =A0My answer on application sharing falling "= out of favor"
>> related
>>> =A0 =A0 =A0 =A0specifically to vendor support for standards-ba= sed
>> application
>>> =A0 =A0 =A0 =A0sharing
>>> =A0 =A0 =A0 =A0(T.120 in particular) - which I thought was res= ponsive to
>> your
>>> =A0 =A0 =A0 =A0original
>>> =A0 =A0 =A0 =A0question. Perhaps I misunderstood it. Anyway th= ere were
>> several
>>> =A0 =A0 =A0 =A0reasons [and perhaps various viewpoints] on why= T.120 was
>> dropped,
>>> =A0 =A0 =A0 =A0though I think it is probably not a useful disc= ussion for
>> this
>>> =A0 =A0 =A0 =A0list. I
>>> =A0 =A0 =A0 =A0know of no other standards-based protocol for a= pplication
>> sharing.
>>>
>>> =A0 =A0I wasn't assuming there was, other than a pure vide= o (and maybe
>>> =A0 =A0audio) stream interface. There are other fora for that = sort of
>>> =A0 =A0thing, but its my impression that this is largely a wor= ld of
>>> =A0 =A0proprietary and defacto standards.
>>>
>>> =A0 =A0 =A0 =A0BTW, it is relatively common for web screen sha= ring to
>> co-exist
>>> =A0 =A0 =A0 =A0with the
>>> =A0 =A0 =A0 =A0videoconferencing presentation methods. For ins= tance, you can
>> have a
>>> =A0 =A0 =A0 =A0stand-alone webex conference, with someone shar= ing their
>> laptop
>>> =A0 =A0 =A0 =A0screen
>>> =A0 =A0 =A0 =A0for the video participants.[/sb]
>>>
>>> =A0 =A0I have done this. But it was cumbersome. IIRC, getting = the
>> sharing
>>> =A0 =A0to be visible in the room I was in required using a vid= eo cable
>> in
>>> =A0 =A0addition to using webex sharing.
>>>
>>> [sb]With our equipment you could use the cable if you wished, = but it
>>> would not be required. Though generally speaking, people are u= sed to
>>> using projectors for presenting. Video systems are providing >> identical
>>
>>> interfaces, so they work the way people expect. For instance, = in IETF
>>> interim meetings the Webex screen is always presented locally,=
>>> frequently using a cable. The chairs may find that cumbersome,= but
>>> they certainly come into the meeting expecting to do it anyway= .[\sb]
>>>
>>> =A0 =A0 =A0 =A0Of course that is still somewhat cumbersome, bu= t presumably
>> it
>> will
>>> =A0 =A0 =A0 =A0be improved over time. Its the UI for driving i= t that is
>> cumbersome,
>>> =A0 =A0 =A0 =A0not the output.
>>>
>>> =A0 =A0 =A0 =A0A key difference is that if the computer output= is via video
>> cable
>>> =A0 =A0 =A0 =A0into the local room controller, then that is pr= obably
>> responsible
>>> =A0 =A0 =A0 =A0for displaying it locally on a display in the r= oom as well as
>>> =A0 =A0 =A0 =A0sending it to the remote end. If the users conn= ect their
>> computers
>>> =A0 =A0 =A0 =A0directly to the MCU, then the capture will come= to the room
>> just
>>> =A0 =A0 =A0 =A0like anything else from the MCU.
>>>
>>> =A0 =A0 =A0 =A0[sb]The standard model for videoconferencing pr= esentations is
>> a
>>> =A0 =A0 =A0 =A0token-controlled transmission. If you don't= have the token,
>> you are
>>> =A0 =A0 =A0 =A0receiving. The local equipment is always respon= sible for
>> display.
>>> =A0 =A0 =A0 =A0Looping the presentation back through the MCU b= ack to the
>>> =A0 =A0 =A0 =A0originating
>>> =A0 =A0 =A0 =A0site wastes bandwidth.
>>>
>>> =A0 =A0 =A0 =A0I don't know if web conferencing solutions = do this
>> differently
>>> =A0 =A0 =A0 =A0or not.
>>> =A0 =A0 =A0 =A0I've always assumed that when I grab the we= bex "ball" I stop
>>> =A0 =A0 =A0 =A0receiving
>>> =A0 =A0 =A0 =A0desktop images. Certainly there is no reason fo= r the server
>> to
>> send
>>> =A0 =A0 =A0 =A0them back to me.[/sb]
>>>
>>>
>>> =A0 =A0Thanks,
>>> =A0 =A0Paul
>>>
>>
>> _______________________________________________
>> clue mailing list
>> clue@ietf.org
>> https://www.ietf.org/mailman/listinfo/clue
>
> _______________________________________________
> clue mailing list
> clue@ietf.org
> https://www.ietf.org/mailman/listinfo/clue

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

--e89a8ff2432b8487b004bf27cfe4-- From br@brianrosen.net Thu May 3 14:18:07 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9773C21F84B2 for ; Thu, 3 May 2012 14:18:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.559 X-Spam-Level: X-Spam-Status: No, score=-102.559 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B-TW1BumTVzR for ; Thu, 3 May 2012 14:18:05 -0700 (PDT) Received: from barmail4.idig.net (barmail4.idig.net [64.34.111.235]) by ietfa.amsl.com (Postfix) with ESMTP id 2D34421F847E for ; Thu, 3 May 2012 14:17:43 -0700 (PDT) X-ASG-Debug-ID: 1336079860-04d03579cbf43e0001-dOUo1C Received: from wwh1.winweblinux.com (wwh1.winweblinux.com [76.74.186.184]) by barmail4.idig.net with ESMTP id bP2WfRXJbSLlXU1K; Thu, 03 May 2012 14:17:40 -0700 (PDT) X-Barracuda-Envelope-From: br@brianrosen.net X-Barracuda-Apparent-Source-IP: 76.74.186.184 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=[156.154.4.14]) by wwh1.winweblinux.com with esmtpa (Exim 4.69) (envelope-from ) id 1SQ3PA-001iBC-Vs; Thu, 03 May 2012 14:17:41 -0700 Mime-Version: 1.0 (Apple Message framework v1257) X-ASG-Orig-Subj: Re: [clue] ways of managing presentations in telepresence sessions Content-Type: multipart/alternative; boundary="Apple-Mail=_6914920D-D9A1-450B-A752-F1F961C91197" From: Brian Rosen In-Reply-To: Date: Thu, 3 May 2012 17:17:36 -0400 Message-Id: References: <4F997E6B.7070501@alum.mit.edu> <4F9B0D81.4040608@alum.mit.edu> <4F9EC454.3060605@alum.mit.edu> <05DD269BD82AA549BC4B2619BBAC466A0109F228@XMB-AMS-206.cisco.com> <4FA15144.9030307@alum.mit.edu> <05DD269BD82AA549BC4B2619BBAC466A0109F407@XMB-AMS-206.cisco.com> <4fa295be.0852b40a.771f.1804@mx.google.com> To: Stephen Botzko X-Mailer: Apple Mail (2.1257) X-Barracuda-Connect: wwh1.winweblinux.com[76.74.186.184] X-Barracuda-Start-Time: 1336079860 X-Barracuda-URL: http://64.34.111.235:8000/cgi-mod/mark.cgi X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.5 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.95904 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message Cc: CLUE , "Johan Ludvig Nielsen \(johaniel\)" Subject: Re: [clue] ways of managing presentations in telepresence sessions X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 03 May 2012 21:18:07 -0000 --Apple-Mail=_6914920D-D9A1-450B-A752-F1F961C91197 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Because it's not a common problem, and there is no right way to do it. Having the telepresence audio/video on one system and the presentation = system on another is probably more common that having them on the same = system. Brian On May 3, 2012, at 4:40 PM, Stephen Botzko wrote: > I have two separate speakerphones from two vendors in one room calling = into the same audio conference. They interact in a way that utterly = fails to deliver usable audio to phones in other locations. We don't = have mechanisms in SIP to represent this or prevent the bad behaviour. =20= >=20 > This is a problem for the IETF because???? >=20 > Stephen Botzko >=20 > On Thu, May 3, 2012 at 6:18 PM, Brian Rosen wrote: > I go back to what I see is the fundamental issue: >=20 > You have two separate systems from two vendors in one room. They = interact in a way that is important to other rooms. We don't have = mechanisms to represent this. >=20 > Brian >=20 > On May 3, 2012, at 10:25 AM, Roni Even wrote: >=20 > > Hi, > > See inline > > Roni > > > >> -----Original Message----- > >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On = Behalf Of > >> Johan Ludvig Nielsen (johaniel) > >> Sent: Thursday, May 03, 2012 4:02 PM > >> To: Paul Kyzivat > >> Cc: CLUE > >> Subject: Re: [clue] ways of managing presentations in telepresence > >> sessions > >> > >> Sorry for being unclear. I am commenting on the implied option of > >> rendering presentation on a separate system, either on one or = several > >> computers or a dedicated endpoint separate from the telepresence = system > >> in the room. > >> > >> My main point is that all audio belonging to a conference and being > >> played back in a room must be controlled by or at least known to = the > >> audio processing unit sending audio _from_ that room. This is to = avoid > >> echo or multi-path problems. > >> > >> One example of such a problem is if a presentation in the form of a > >> movie with a soundtrack is played back on a computer separate from = the > >> telepresence system in the room. The microphone system in the room = will > >> pick up the sound from the computer's loudspeakers and happily = transmit > >> that as voice into the conference. The presentation audio is then > >> delivered to other sites through two different paths with different > >> delays, one of them with poor quality. > > > > This is not a problem of the current protocols, you can send two = audio > > streams in SIP and assign a different content attribute to each of = them. The > > issue of the local echo of the movie sound to the people audio is a = local > > system issue and not a standard issue. As for handling two audio = streams > > this will require a definition like H.239 for this case in order to = achieve > > interoperability. > >> > >> The other (and totally separate) point I am making is that with = CLUE we > >> will have the ability to send presentation audio as a separate = stream, > >> and that we are happy about that. Today locally input presentation > >> audio is most often mixed with the mic signal and sent in the main > >> audio stream (which can be stereo). There is no H.239 equivalent = for > >> audio. > > > > Sending two separate audio is not a CLUE feature, it can be done by = offering > > two audio RTP sessions for example. > > > >> > >> Regards > >> Johan > >> > >> > >> > >> -----Original Message----- > >> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > >> Sent: 2. mai 2012 17:23 > >> To: Johan Ludvig Nielsen (johaniel) > >> Cc: Stephen Botzko; CLUE > >> Subject: Re: [clue] ways of managing presentations in telepresence > >> sessions > >> > >> On 5/2/12 8:06 AM, Johan Ludvig Nielsen (johaniel) wrote: > >>> I just want to remind you all that presentation often means video > >>> _and_ audio, for instance a movie clip with a stereo soundtrack. > >>> Sometimes presentation means only audio. Hook up your favourite > >> device > >> > >>> and share a music clip or an interesting recording. > >>> > >>> Any presentation audio played back locally must be controlled by, = or > >>> at least be exactly (in sample sync) known to, the local = telepresence > >>> system controller. A totally separate endpoint for presentation = will > >>> therefore cause some practical problems. > >>> > >>> By the way, one very useful effect of CLUE is the ability for > >>> receiving endpoints to distinguish between audio from live talking > >>> sources and presentations/recordings. > >> > >> I'm not sure I understand the point you are making. > >> Certainly it is true that a presentation may consist of audio and > >> video. > >> But its not just presentations that can contain paired audio and = video. > >> When we have many audio and video captures, there could be several > >> pairs. > >> > >> RFC3388 provides a way (a=3Dmid:ls) to indicate when lip sync is > >> required. > >> Do we need more than that? Should advertisements indicate desirable > >> audio/video pairings so that selection can take that into account? > >> > >> Thanks, > >> Paul > >> > >>> Johan > >>> > >>> *From:*clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On > >> Behalf > >> > >>> Of *Stephen Botzko > >>> *Sent:* 1. mai 2012 09:11 > >>> *To:* Paul Kyzivat > >>> *Cc:* CLUE > >>> *Subject:* Re: [clue] ways of managing presentations in = telepresence > >>> sessions > >>> > >>> On Mon, Apr 30, 2012 at 12:56 PM, Paul Kyzivat = >>> > wrote: > >>> > >>> On 4/28/12 1:18 PM, Stephen Botzko wrote: > >>> > >>> [sb] As I mentioned above, the existing solutions usually include = a > >>> screen-scrape application, so you don't have to use a video cable. > >>> This is essentially the same as using Webex for presenting (but = not > >>> remote control). > >>> > >>> How are these solutions connected? Does the captured application = data > >>> go to the local room controller, or to an MCU in the middle of the = TP > >>> session? Or something else? > >>> > >>> [sb] They are normally connected to the local room telepresence > >> system. > >>> Again, the people in the local room also need to see the > >> presentation, > >> > >>> so this is the most direct and also is the most bandwidth = efficient > >>> approach. Another aspect is that the rooms can and are used purely > >>> locally (with no remote systems at all), and presentations also = need > >>> to work in that situation. BTW I think adding requirements for > >> support > >> > >>> of multiple endpoints in the same room is an unwise path - this is > >> not > >> > >>> SPLICES, and we have enough to do already. I agree with folks who = are > >>> saying it is out of scope[/sb] > >>> > >>> Also, even though Webex allows remote control, in my > >>> experience that feature is not used as much as simple > >>> presenting. I am > >>> not saying it has no value, just that the most common case = I > >> see > >>> is a > >>> simple presentation. > >>> > >>> That is my experience as well. I wasn't thinking about the > >>> multi-user-control aspect. > >>> > >>> Supporting the video cable still has value, especially if = you > >>> have guest > >>> presenter who does not have access to your local network. > >> Most > >>> of those > >>> presenters are expecting to use a projector, so they have = the > >> cables > >>> with them. > >>> > >>> Surely. In this case, I presume the cable connects to the local > >> room > >>> controller. If there are multiple cable connectors (e.g. one at > >> each > >>> seat) do they show up as multiple presentation streams? Or is > >> there > >>> some sort of switch and floor control? If so, how does one = manage > >>> the floor control? > >>> > >>> [sb] Today there is one presenter at a time. With multiple > >> cables, > >>> there is usually a button at each spot, and if you press it you > >>> become the presenter (most recent request wins is the policy). > >>> Normal social courtesies handle conflict, so there is no real > >> need > >>> for formal floor control. This happens even in ordinary webex > >>> conferences - if someone grabs the ball when they shouldn't = have > >> it, > >>> people say something and it gets resolved. Similarly, if = someone > >>> needs the ball. More precisely, the presenting video system = holds > >>> the token for the room. With H.239, the MCU (if there is one) > >> grants > >>> it, using whatever policy it wants, and can revoke it at any > >> time. > >>> In point-to-point calls, the far end SHALL grant it upon = request, > >> so > >>> in that case the turn-taking policy is mandated in the = standard. > >>> Multiple presenters in the same room is up to the local room > >> policy > >>> - there is no standard, and in my opinion none is needed. The > >> token > >>> remains owned by the local video system, it is allowed to = present > >>> whatever local source it wishes. [/sb] > >>> > >>> My answer on application sharing falling "out of favor" > >> related > >>> specifically to vendor support for standards-based > >> application > >>> sharing > >>> (T.120 in particular) - which I thought was responsive to > >> your > >>> original > >>> question. Perhaps I misunderstood it. Anyway there were > >> several > >>> reasons [and perhaps various viewpoints] on why T.120 was > >> dropped, > >>> though I think it is probably not a useful discussion for > >> this > >>> list. I > >>> know of no other standards-based protocol for application > >> sharing. > >>> > >>> I wasn't assuming there was, other than a pure video (and maybe > >>> audio) stream interface. There are other fora for that sort of > >>> thing, but its my impression that this is largely a world of > >>> proprietary and defacto standards. > >>> > >>> BTW, it is relatively common for web screen sharing to > >> co-exist > >>> with the > >>> videoconferencing presentation methods. For instance, you = can > >> have a > >>> stand-alone webex conference, with someone sharing their > >> laptop > >>> screen > >>> for the video participants.[/sb] > >>> > >>> I have done this. But it was cumbersome. IIRC, getting the > >> sharing > >>> to be visible in the room I was in required using a video cable > >> in > >>> addition to using webex sharing. > >>> > >>> [sb]With our equipment you could use the cable if you wished, but = it > >>> would not be required. Though generally speaking, people are used = to > >>> using projectors for presenting. Video systems are providing > >> identical > >> > >>> interfaces, so they work the way people expect. For instance, in = IETF > >>> interim meetings the Webex screen is always presented locally, > >>> frequently using a cable. The chairs may find that cumbersome, but > >>> they certainly come into the meeting expecting to do it = anyway.[\sb] > >>> > >>> Of course that is still somewhat cumbersome, but presumably > >> it > >> will > >>> be improved over time. Its the UI for driving it that is > >> cumbersome, > >>> not the output. > >>> > >>> A key difference is that if the computer output is via = video > >> cable > >>> into the local room controller, then that is probably > >> responsible > >>> for displaying it locally on a display in the room as well = as > >>> sending it to the remote end. If the users connect their > >> computers > >>> directly to the MCU, then the capture will come to the room > >> just > >>> like anything else from the MCU. > >>> > >>> [sb]The standard model for videoconferencing presentations = is > >> a > >>> token-controlled transmission. If you don't have the token, > >> you are > >>> receiving. The local equipment is always responsible for > >> display. > >>> Looping the presentation back through the MCU back to the > >>> originating > >>> site wastes bandwidth. > >>> > >>> I don't know if web conferencing solutions do this > >> differently > >>> or not. > >>> I've always assumed that when I grab the webex "ball" I = stop > >>> receiving > >>> desktop images. Certainly there is no reason for the server > >> to > >> send > >>> them back to me.[/sb] > >>> > >>> > >>> Thanks, > >>> Paul > >>> > >> > >> _______________________________________________ > >> 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 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue >=20 --Apple-Mail=_6914920D-D9A1-450B-A752-F1F961C91197 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=iso-8859-1 Because it's not a common problem, and there is no right way to do it.

Having the telepresence audio/video on one system and the presentation system on another is probably more common that having them on the same system.

Brian

On May 3, 2012, at 4:40 PM, Stephen Botzko wrote:

I have two separate speakerphones from two vendors in one room calling into the same audio conference.  They interact in a way that utterly fails to deliver usable audio to phones in other locations.  We don't have mechanisms in SIP to represent this or prevent the bad behaviour. 

This is a problem for the IETF because????

Stephen Botzko

On Thu, May 3, 2012 at 6:18 PM, Brian Rosen <br@brianrosen.net> wrote:
I go back to what I see is the fundamental issue:

You have two separate systems from two vendors in one room.  They interact in a way that is important to other rooms.  We don't have mechanisms to represent this.

Brian

On May 3, 2012, at 10:25 AM, Roni Even wrote:

> Hi,
> See inline
> Roni
>
>> -----Original Message-----
>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of
>> Johan Ludvig Nielsen (johaniel)
>> Sent: Thursday, May 03, 2012 4:02 PM
>> To: Paul Kyzivat
>> Cc: CLUE
>> Subject: Re: [clue] ways of managing presentations in telepresence
>> sessions
>>
>> Sorry for being unclear. I am commenting on the implied option of
>> rendering presentation on a separate system, either on one or several
>> computers or a dedicated endpoint separate from the telepresence system
>> in the room.
>>
>> My main point is that all audio belonging to a conference and being
>> played back in a room must be controlled by or at least known to the
>> audio processing unit sending audio _from_ that room. This is to avoid
>> echo or multi-path problems.
>>
>> One example of such a problem is if a presentation in the form of a
>> movie with a soundtrack is played back on a computer separate from the
>> telepresence system in the room. The microphone system in the room will
>> pick up the sound from the computer's loudspeakers and happily transmit
>> that as voice into the conference. The presentation audio is then
>> delivered to other sites through two different paths with different
>> delays, one of them with poor quality.
>
> This is not a problem of the current protocols, you can send two audio
> streams in SIP and assign a different content attribute to each of them. The
> issue of the local echo of the movie sound to the people audio is a local
> system issue and not a standard issue. As for handling two audio streams
> this will require a definition like H.239 for this case in order to achieve
> interoperability.
>>
>> The other (and totally separate) point I am making is that with CLUE we
>> will have the ability to send presentation audio as a separate stream,
>> and that we are happy about that. Today locally input presentation
>> audio is most often mixed with the mic signal and sent in the main
>> audio stream (which can be stereo). There is no H.239 equivalent for
>> audio.
>
> Sending two separate audio is not a CLUE feature, it can be done by offering
> two audio RTP sessions for example.
>
>>
>> Regards
>> Johan
>>
>>
>>
>> -----Original Message-----
>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]
>> Sent: 2. mai 2012 17:23
>> To: Johan Ludvig Nielsen (johaniel)
>> Cc: Stephen Botzko; CLUE
>> Subject: Re: [clue] ways of managing presentations in telepresence
>> sessions
>>
>> On 5/2/12 8:06 AM, Johan Ludvig Nielsen (johaniel) wrote:
>>> I just want to remind you all that presentation often means video
>>> _and_ audio, for instance a movie clip with a stereo soundtrack.
>>> Sometimes presentation means only audio. Hook up your favourite
>> device
>>
>>> and share a music clip or an interesting recording.
>>>
>>> Any presentation audio played back locally must be controlled by, or
>>> at least be exactly (in sample sync) known to, the local telepresence
>>> system controller. A totally separate endpoint for presentation will
>>> therefore cause some practical problems.
>>>
>>> By the way, one very useful effect of CLUE is the ability for
>>> receiving endpoints to distinguish between audio from live talking
>>> sources and presentations/recordings.
>>
>> I'm not sure I understand the point you are making.
>> Certainly it is true that a presentation may consist of audio and
>> video.
>> But its not just presentations that can contain paired audio and video.
>> When we have many audio and video captures, there could be several
>> pairs.
>>
>> RFC3388 provides a way (a=mid:ls) to indicate when lip sync is
>> required.
>> Do we need more than that? Should advertisements indicate desirable
>> audio/video pairings so that selection can take that into account?
>>
>>      Thanks,
>>      Paul
>>
>>> Johan
>>>
>>> *From:*clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On
>> Behalf
>>
>>> Of *Stephen Botzko
>>> *Sent:* 1. mai 2012 09:11
>>> *To:* Paul Kyzivat
>>> *Cc:* CLUE
>>> *Subject:* Re: [clue] ways of managing presentations in telepresence
>>> sessions
>>>
>>> On Mon, Apr 30, 2012 at 12:56 PM, Paul Kyzivat <pkyzivat@alum.mit.edu
>>> <mailto:pkyzivat@alum.mit.edu>> wrote:
>>>
>>> On 4/28/12 1:18 PM, Stephen Botzko wrote:
>>>
>>> [sb] As I mentioned above, the existing solutions usually include a
>>> screen-scrape application, so you don't have to use a video cable.
>>> This is essentially the same as using Webex for presenting (but not
>>> remote control).
>>>
>>> How are these solutions connected? Does the captured application data
>>> go to the local room controller, or to an MCU in the middle of the TP
>>> session? Or something else?
>>>
>>> [sb] They are normally connected to the local room telepresence
>> system.
>>> Again, the people in the local room also need to see the
>> presentation,
>>
>>> so this is the most direct and also is the most bandwidth efficient
>>> approach. Another aspect is that the rooms can and are used purely
>>> locally (with no remote systems at all), and presentations also need
>>> to work in that situation. BTW I think adding requirements for
>> support
>>
>>> of multiple endpoints in the same room is an unwise path - this is
>> not
>>
>>> SPLICES, and we have enough to do already. I agree with folks who are
>>> saying it is out of scope[/sb]
>>>
>>>        Also, even though Webex allows remote control, in my
>>>        experience that feature is not used as much as simple
>>>        presenting. I am
>>>        not saying it has no value, just that the most common case I
>> see
>>>        is a
>>>        simple presentation.
>>>
>>>    That is my experience as well. I wasn't thinking about the
>>>    multi-user-control aspect.
>>>
>>>        Supporting the video cable still has value, especially if you
>>>        have guest
>>>        presenter who does not have access to your local network.
>> Most
>>>        of those
>>>        presenters are expecting to use a projector, so they have the
>> cables
>>>        with them.
>>>
>>>    Surely. In this case, I presume the cable connects to the local
>> room
>>>    controller. If there are multiple cable connectors (e.g. one at
>> each
>>>    seat) do they show up as multiple presentation streams? Or is
>> there
>>>    some sort of switch and floor control? If so, how does one manage
>>>    the floor control?
>>>
>>>    [sb] Today there is one presenter at a time. With multiple
>> cables,
>>>    there is usually a button at each spot, and if you press it you
>>>    become the presenter (most recent request wins is the policy).
>>>    Normal social courtesies handle conflict, so there is no real
>> need
>>>    for formal floor control. This happens even in ordinary webex
>>>    conferences - if someone grabs the ball when they shouldn't have
>> it,
>>>    people say something and it gets resolved. Similarly, if someone
>>>    needs the ball. More precisely, the presenting video system holds
>>>    the token for the room. With H.239, the MCU (if there is one)
>> grants
>>>    it, using whatever policy it wants, and can revoke it at any
>> time.
>>>    In point-to-point calls, the far end SHALL grant it upon request,
>> so
>>>    in that case the turn-taking policy is mandated in the standard.
>>>    Multiple presenters in the same room is up to the local room
>> policy
>>>    - there is no standard, and in my opinion none is needed. The
>> token
>>>    remains owned by the local video system, it is allowed to present
>>>    whatever local source it wishes. [/sb]
>>>
>>>        My answer on application sharing falling "out of favor"
>> related
>>>        specifically to vendor support for standards-based
>> application
>>>        sharing
>>>        (T.120 in particular) - which I thought was responsive to
>> your
>>>        original
>>>        question. Perhaps I misunderstood it. Anyway there were
>> several
>>>        reasons [and perhaps various viewpoints] on why T.120 was
>> dropped,
>>>        though I think it is probably not a useful discussion for
>> this
>>>        list. I
>>>        know of no other standards-based protocol for application
>> sharing.
>>>
>>>    I wasn't assuming there was, other than a pure video (and maybe
>>>    audio) stream interface. There are other fora for that sort of
>>>    thing, but its my impression that this is largely a world of
>>>    proprietary and defacto standards.
>>>
>>>        BTW, it is relatively common for web screen sharing to
>> co-exist
>>>        with the
>>>        videoconferencing presentation methods. For instance, you can
>> have a
>>>        stand-alone webex conference, with someone sharing their
>> laptop
>>>        screen
>>>        for the video participants.[/sb]
>>>
>>>    I have done this. But it was cumbersome. IIRC, getting the
>> sharing
>>>    to be visible in the room I was in required using a video cable
>> in
>>>    addition to using webex sharing.
>>>
>>> [sb]With our equipment you could use the cable if you wished, but it
>>> would not be required. Though generally speaking, people are used to
>>> using projectors for presenting. Video systems are providing
>> identical
>>
>>> interfaces, so they work the way people expect. For instance, in IETF
>>> interim meetings the Webex screen is always presented locally,
>>> frequently using a cable. The chairs may find that cumbersome, but
>>> they certainly come into the meeting expecting to do it anyway.[\sb]
>>>
>>>        Of course that is still somewhat cumbersome, but presumably
>> it
>> will
>>>        be improved over time. Its the UI for driving it that is
>> cumbersome,
>>>        not the output.
>>>
>>>        A key difference is that if the computer output is via video
>> cable
>>>        into the local room controller, then that is probably
>> responsible
>>>        for displaying it locally on a display in the room as well as
>>>        sending it to the remote end. If the users connect their
>> computers
>>>        directly to the MCU, then the capture will come to the room
>> just
>>>        like anything else from the MCU.
>>>
>>>        [sb]The standard model for videoconferencing presentations is
>> a
>>>        token-controlled transmission. If you don't have the token,
>> you are
>>>        receiving. The local equipment is always responsible for
>> display.
>>>        Looping the presentation back through the MCU back to the
>>>        originating
>>>        site wastes bandwidth.
>>>
>>>        I don't know if web conferencing solutions do this
>> differently
>>>        or not.
>>>        I've always assumed that when I grab the webex "ball" I stop
>>>        receiving
>>>        desktop images. Certainly there is no reason for the server
>> to
>> send
>>>        them back to me.[/sb]
>>>
>>>
>>>    Thanks,
>>>    Paul
>>>
>>
>> _______________________________________________
>> clue mailing list
>> clue@ietf.org
>> https://www.ietf.org/mailman/listinfo/clue
>
> _______________________________________________
> clue mailing list
> clue@ietf.org
> https://www.ietf.org/mailman/listinfo/clue

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


--Apple-Mail=_6914920D-D9A1-450B-A752-F1F961C91197-- From Even.roni@huawei.com Thu May 3 22:33:42 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC9CA21F853D for ; Thu, 3 May 2012 22:33:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QGzWeKrkSkGo for ; Thu, 3 May 2012 22:33:41 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id C920721F841D for ; Thu, 3 May 2012 22:33:40 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AFU89530; Fri, 04 May 2012 01:33:39 -0400 (EDT) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 3 May 2012 22:32:00 -0700 Received: from SZXEML416-HUB.china.huawei.com (10.82.67.155) by dfweml404-hub.china.huawei.com (10.193.5.203) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 3 May 2012 22:31:58 -0700 Received: from SZXEML536-MBX.china.huawei.com ([10.82.67.115]) by szxeml416-hub.china.huawei.com ([10.82.67.155]) with mapi id 14.01.0323.003; Fri, 4 May 2012 13:31:54 +0800 From: Roni even To: Brian Rosen , Stephen Botzko Thread-Topic: [clue] ways of managing presentations in telepresence sessions Thread-Index: AQHNI84a7nkR+jw5XUCzK/waIPY5UJas6IQAgAHAxoCAAU7lgIADHpMAgADuwoCAAeTjgIAANrgAgAFrHoCAABcrAIAAH7YAgABJCQCAAApzAIABDnlC Date: Fri, 4 May 2012 05:31:54 +0000 Message-ID: References: <4F997E6B.7070501@alum.mit.edu> <4F9B0D81.4040608@alum.mit.edu> <4F9EC454.3060605@alum.mit.edu> <05DD269BD82AA549BC4B2619BBAC466A0109F228@XMB-AMS-206.cisco.com> <4FA15144.9030307@alum.mit.edu> <05DD269BD82AA549BC4B2619BBAC466A0109F407@XMB-AMS-206.cisco.com> <4fa295be.0852b40a.771f.1804@mx.google.com> , In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.24.1.69] Content-Type: multipart/alternative; boundary="_000_EADCEEE0AE4A7F46BD61061696794D9819E67669szxeml536mbx_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: CLUE , "Johan Ludvig Nielsen \(johaniel\)" Subject: Re: [clue] ways of managing presentations in telepresence sessions X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 04 May 2012 05:33:43 -0000 X-List-Received-Date: Fri, 04 May 2012 05:33:43 -0000 --_000_EADCEEE0AE4A7F46BD61061696794D9819E67669szxeml536mbx_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Brian, I agree that this is a problem, but it is not a CLUE problem. I am wonderin= g if it is for the IETF but it can be discussed in Disptach or SPLICE. The problem is not two systems but two different applications that do not h= ave a common API or that the presentation application is not based on any s= tandard that allows an implementer to create one application. Roni ________________________________ From: clue-bounces@ietf.org [clue-bounces@ietf.org] on behalf of Brian Rose= n [br@brianrosen.net] Sent: Friday, May 04, 2012 0:17 To: Stephen Botzko Cc: CLUE; Johan Ludvig Nielsen (johaniel) Subject: Re: [clue] ways of managing presentations in telepresence sessions Because it's not a common problem, and there is no right way to do it. Having the telepresence audio/video on one system and the presentation syst= em on another is probably more common that having them on the same system. Brian On May 3, 2012, at 4:40 PM, Stephen Botzko wrote: I have two separate speakerphones from two vendors in one room calling into= the same audio conference. They interact in a way that utterly fails to d= eliver usable audio to phones in other locations. We don't have mechanisms= in SIP to represent this or prevent the bad behaviour. This is a problem for the IETF because???? Stephen Botzko On Thu, May 3, 2012 at 6:18 PM, Brian Rosen > wrote: I go back to what I see is the fundamental issue: You have two separate systems from two vendors in one room. They interact = in a way that is important to other rooms. We don't have mechanisms to rep= resent this. Brian On May 3, 2012, at 10:25 AM, Roni Even wrote: > Hi, > See inline > Roni > >> -----Original Message----- >> From: clue-bounces@ietf.org [mailto:clue-b= ounces@ietf.org] On Behalf Of >> Johan Ludvig Nielsen (johaniel) >> Sent: Thursday, May 03, 2012 4:02 PM >> To: Paul Kyzivat >> Cc: CLUE >> Subject: Re: [clue] ways of managing presentations in telepresence >> sessions >> >> Sorry for being unclear. I am commenting on the implied option of >> rendering presentation on a separate system, either on one or several >> computers or a dedicated endpoint separate from the telepresence system >> in the room. >> >> My main point is that all audio belonging to a conference and being >> played back in a room must be controlled by or at least known to the >> audio processing unit sending audio _from_ that room. This is to avoid >> echo or multi-path problems. >> >> One example of such a problem is if a presentation in the form of a >> movie with a soundtrack is played back on a computer separate from the >> telepresence system in the room. The microphone system in the room will >> pick up the sound from the computer's loudspeakers and happily transmit >> that as voice into the conference. The presentation audio is then >> delivered to other sites through two different paths with different >> delays, one of them with poor quality. > > This is not a problem of the current protocols, you can send two audio > streams in SIP and assign a different content attribute to each of them. = The > issue of the local echo of the movie sound to the people audio is a local > system issue and not a standard issue. As for handling two audio streams > this will require a definition like H.239 for this case in order to achie= ve > interoperability. >> >> The other (and totally separate) point I am making is that with CLUE we >> will have the ability to send presentation audio as a separate stream, >> and that we are happy about that. Today locally input presentation >> audio is most often mixed with the mic signal and sent in the main >> audio stream (which can be stereo). There is no H.239 equivalent for >> audio. > > Sending two separate audio is not a CLUE feature, it can be done by offer= ing > two audio RTP sessions for example. > >> >> Regards >> Johan >> >> >> >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >> Sent: 2. mai 2012 17:23 >> To: Johan Ludvig Nielsen (johaniel) >> Cc: Stephen Botzko; CLUE >> Subject: Re: [clue] ways of managing presentations in telepresence >> sessions >> >> On 5/2/12 8:06 AM, Johan Ludvig Nielsen (johaniel) wrote: >>> I just want to remind you all that presentation often means video >>> _and_ audio, for instance a movie clip with a stereo soundtrack. >>> Sometimes presentation means only audio. Hook up your favourite >> device >> >>> and share a music clip or an interesting recording. >>> >>> Any presentation audio played back locally must be controlled by, or >>> at least be exactly (in sample sync) known to, the local telepresence >>> system controller. A totally separate endpoint for presentation will >>> therefore cause some practical problems. >>> >>> By the way, one very useful effect of CLUE is the ability for >>> receiving endpoints to distinguish between audio from live talking >>> sources and presentations/recordings. >> >> I'm not sure I understand the point you are making. >> Certainly it is true that a presentation may consist of audio and >> video. >> But its not just presentations that can contain paired audio and video. >> When we have many audio and video captures, there could be several >> pairs. >> >> RFC3388 provides a way (a=3Dmid:ls) to indicate when lip sync is >> required. >> Do we need more than that? Should advertisements indicate desirable >> audio/video pairings so that selection can take that into account? >> >> Thanks, >> Paul >> >>> Johan >>> >>> *From:*clue-bounces@ietf.org [mailto:clue= -bounces@ietf.org] *On >> Behalf >> >>> Of *Stephen Botzko >>> *Sent:* 1. mai 2012 09:11 >>> *To:* Paul Kyzivat >>> *Cc:* CLUE >>> *Subject:* Re: [clue] ways of managing presentations in telepresence >>> sessions >>> >>> On Mon, Apr 30, 2012 at 12:56 PM, Paul Kyzivat >>> >> wrote: >>> >>> On 4/28/12 1:18 PM, Stephen Botzko wrote: >>> >>> [sb] As I mentioned above, the existing solutions usually include a >>> screen-scrape application, so you don't have to use a video cable. >>> This is essentially the same as using Webex for presenting (but not >>> remote control). >>> >>> How are these solutions connected? Does the captured application data >>> go to the local room controller, or to an MCU in the middle of the TP >>> session? Or something else? >>> >>> [sb] They are normally connected to the local room telepresence >> system. >>> Again, the people in the local room also need to see the >> presentation, >> >>> so this is the most direct and also is the most bandwidth efficient >>> approach. Another aspect is that the rooms can and are used purely >>> locally (with no remote systems at all), and presentations also need >>> to work in that situation. BTW I think adding requirements for >> support >> >>> of multiple endpoints in the same room is an unwise path - this is >> not >> >>> SPLICES, and we have enough to do already. I agree with folks who are >>> saying it is out of scope[/sb] >>> >>> Also, even though Webex allows remote control, in my >>> experience that feature is not used as much as simple >>> presenting. I am >>> not saying it has no value, just that the most common case I >> see >>> is a >>> simple presentation. >>> >>> That is my experience as well. I wasn't thinking about the >>> multi-user-control aspect. >>> >>> Supporting the video cable still has value, especially if you >>> have guest >>> presenter who does not have access to your local network. >> Most >>> of those >>> presenters are expecting to use a projector, so they have the >> cables >>> with them. >>> >>> Surely. In this case, I presume the cable connects to the local >> room >>> controller. If there are multiple cable connectors (e.g. one at >> each >>> seat) do they show up as multiple presentation streams? Or is >> there >>> some sort of switch and floor control? If so, how does one manage >>> the floor control? >>> >>> [sb] Today there is one presenter at a time. With multiple >> cables, >>> there is usually a button at each spot, and if you press it you >>> become the presenter (most recent request wins is the policy). >>> Normal social courtesies handle conflict, so there is no real >> need >>> for formal floor control. This happens even in ordinary webex >>> conferences - if someone grabs the ball when they shouldn't have >> it, >>> people say something and it gets resolved. Similarly, if someone >>> needs the ball. More precisely, the presenting video system holds >>> the token for the room. With H.239, the MCU (if there is one) >> grants >>> it, using whatever policy it wants, and can revoke it at any >> time. >>> In point-to-point calls, the far end SHALL grant it upon request, >> so >>> in that case the turn-taking policy is mandated in the standard. >>> Multiple presenters in the same room is up to the local room >> policy >>> - there is no standard, and in my opinion none is needed. The >> token >>> remains owned by the local video system, it is allowed to present >>> whatever local source it wishes. [/sb] >>> >>> My answer on application sharing falling "out of favor" >> related >>> specifically to vendor support for standards-based >> application >>> sharing >>> (T.120 in particular) - which I thought was responsive to >> your >>> original >>> question. Perhaps I misunderstood it. Anyway there were >> several >>> reasons [and perhaps various viewpoints] on why T.120 was >> dropped, >>> though I think it is probably not a useful discussion for >> this >>> list. I >>> know of no other standards-based protocol for application >> sharing. >>> >>> I wasn't assuming there was, other than a pure video (and maybe >>> audio) stream interface. There are other fora for that sort of >>> thing, but its my impression that this is largely a world of >>> proprietary and defacto standards. >>> >>> BTW, it is relatively common for web screen sharing to >> co-exist >>> with the >>> videoconferencing presentation methods. For instance, you can >> have a >>> stand-alone webex conference, with someone sharing their >> laptop >>> screen >>> for the video participants.[/sb] >>> >>> I have done this. But it was cumbersome. IIRC, getting the >> sharing >>> to be visible in the room I was in required using a video cable >> in >>> addition to using webex sharing. >>> >>> [sb]With our equipment you could use the cable if you wished, but it >>> would not be required. Though generally speaking, people are used to >>> using projectors for presenting. Video systems are providing >> identical >> >>> interfaces, so they work the way people expect. For instance, in IETF >>> interim meetings the Webex screen is always presented locally, >>> frequently using a cable. The chairs may find that cumbersome, but >>> they certainly come into the meeting expecting to do it anyway.[\sb] >>> >>> Of course that is still somewhat cumbersome, but presumably >> it >> will >>> be improved over time. Its the UI for driving it that is >> cumbersome, >>> not the output. >>> >>> A key difference is that if the computer output is via video >> cable >>> into the local room controller, then that is probably >> responsible >>> for displaying it locally on a display in the room as well as >>> sending it to the remote end. If the users connect their >> computers >>> directly to the MCU, then the capture will come to the room >> just >>> like anything else from the MCU. >>> >>> [sb]The standard model for videoconferencing presentations is >> a >>> token-controlled transmission. If you don't have the token, >> you are >>> receiving. The local equipment is always responsible for >> display. >>> Looping the presentation back through the MCU back to the >>> originating >>> site wastes bandwidth. >>> >>> I don't know if web conferencing solutions do this >> differently >>> or not. >>> I've always assumed that when I grab the webex "ball" I stop >>> receiving >>> desktop images. Certainly there is no reason for the server >> to >> send >>> them back to me.[/sb] >>> >>> >>> Thanks, >>> Paul >>> >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue --_000_EADCEEE0AE4A7F46BD61061696794D9819E67669szxeml536mbx_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Brian,

I agree that this is a problem, but it is not a CLUE problem. I am wonde= ring if it is for the IETF but it can be discussed in Disptach<= a> or SPLICE.

 

The problem is not two systems but two different applications that do no= t have a common API or that the presentation application is not based on an= y standard that allows an implementer to create one application= .

 

 

Roni

From: clue-bounces@ietf.org [clue-bounces@= ietf.org] on behalf of Brian Rosen [br@brianrosen.net]
Sent: Friday, May 04, 2012 0:17
To: Stephen Botzko
Cc: CLUE; Johan Ludvig Nielsen (johaniel)
Subject: Re: [clue] ways of managing presentations in telepresence s= essions

Because it's not a common problem, and there is no right way to do it.

Having the telepresence audio/video on one system and the presentation= system on another is probably more common that having them on the same sys= tem.

Brian

On May 3, 2012, at 4:40 PM, Stephen Botzko wrote:

I have two separate speakerphones from two vendor= s in one room calling into the same audio conference.  They interact i= n a way that utterly fails to deliver usable audio to phones in other locat= ions.  We don't have mechanisms in SIP to represent this or prevent the bad behaviour. 

This is a problem for the IETF because????

Stephen Botzko

On Thu, May 3, 2012 at 6:18 PM, Brian Rosen <br@brianrosen.ne= t> wrote:
I go back to what I see is the fundamental issue:

You have two separate systems from two vendors in one room.  They inte= ract in a way that is important to other rooms.  We don't have mechani= sms to represent this.

Brian

On May 3, 2012, at 10:25 AM, Roni Even wrote:

> Hi,
> See inline
> Roni
>
>> -----Original Message-----
>> From: c= lue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of
>> Johan Ludvig Nielsen (johaniel)
>> Sent: Thursday, May 03, 2012 4:02 PM
>> To: Paul Kyzivat
>> Cc: CLUE
>> Subject: Re: [clue] ways of managing presentations in telepresence=
>> sessions
>>
>> Sorry for being unclear. I am commenting on the implied option of<= br> >> rendering presentation on a separate system, either on one or seve= ral
>> computers or a dedicated endpoint separate from the telepresence s= ystem
>> in the room.
>>
>> My main point is that all audio belonging to a conference and bein= g
>> played back in a room must be controlled by or at least known to t= he
>> audio processing unit sending audio _from_ that room. This is to a= void
>> echo or multi-path problems.
>>
>> One example of such a problem is if a presentation in the form of = a
>> movie with a soundtrack is played back on a computer separate from= the
>> telepresence system in the room. The microphone system in the room= will
>> pick up the sound from the computer's loudspeakers and happily tra= nsmit
>> that as voice into the conference. The presentation audio is then<= br> >> delivered to other sites through two different paths with differen= t
>> delays, one of them with poor quality.
>
> This is not a problem of the current protocols, you can send two audio=
> streams in SIP and assign a different content attribute to each of the= m. The
> issue of the local echo of the movie sound to the people audio is a lo= cal
> system issue and not a standard issue. As for handling two audio strea= ms
> this will require a definition like H.239 for this case in order to ac= hieve
> interoperability.
>>
>> The other (and totally separate) point I am making is that with CL= UE we
>> will have the ability to send presentation audio as a separate str= eam,
>> and that we are happy about that. Today locally input presentation=
>> audio is most often mixed with the mic signal and sent in the main=
>> audio stream (which can be stereo). There is no H.239 equivalent f= or
>> audio.
>
> Sending two separate audio is not a CLUE feature, it can be done by of= fering
> two audio RTP sessions for example.
>
>>
>> Regards
>> Johan
>>
>>
>>
>> -----Original Message-----
>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]
>> Sent: 2. mai 2012 17:23
>> To: Johan Ludvig Nielsen (johaniel)
>> Cc: Stephen Botzko; CLUE
>> Subject: Re: [clue] ways of managing presentations in telepresence=
>> sessions
>>
>> On 5/2/12 8:06 AM, Johan Ludvig Nielsen (johaniel) wrote:
>>> I just want to remind you all that presentation often means vi= deo
>>> _and_ audio, for instance a movie clip with a stereo soundtrac= k.
>>> Sometimes presentation means only audio. Hook up your favourit= e
>> device
>>
>>> and share a music clip or an interesting recording.
>>>
>>> Any presentation audio played back locally must be controlled = by, or
>>> at least be exactly (in sample sync) known to, the local telep= resence
>>> system controller. A totally separate endpoint for presentatio= n will
>>> therefore cause some practical problems.
>>>
>>> By the way, one very useful effect of CLUE is the ability for<= br> >>> receiving endpoints to distinguish between audio from live tal= king
>>> sources and presentations/recordings.
>>
>> I'm not sure I understand the point you are making.
>> Certainly it is true that a presentation may consist of audio and<= br> >> video.
>> But its not just presentations that can contain paired audio and v= ideo.
>> When we have many audio and video captures, there could be several=
>> pairs.
>>
>> RFC3388 provides a way (a=3Dmid:ls) to indicate when lip sync is >> required.
>> Do we need more than that? Should advertisements indicate desirabl= e
>> audio/video pairings so that selection can take that into account?=
>>
>>      Thanks,
>>      Paul
>>
>>> Johan
>>>
>>> *From:*clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On
>> Behalf
>>
>>> Of *Stephen Botzko
>>> *Sent:* 1. mai 2012 09:11
>>> *To:* Paul Kyzivat
>>> *Cc:* CLUE
>>> *Subject:* Re: [clue] ways of managing presentations in telepr= esence
>>> sessions
>>>
>>> On Mon, Apr 30, 2012 at 12:56 PM, Paul Kyzivat <pkyzivat@alum.mit.edu >>> <mailto:pkyzivat@alum.mit.edu>> wrote:
>>>
>>> On 4/28/12 1:18 PM, Stephen Botzko wrote:
>>>
>>> [sb] As I mentioned above, the existing solutions usually incl= ude a
>>> screen-scrape application, so you don't have to use a video ca= ble.
>>> This is essentially the same as using Webex for presenting (bu= t not
>>> remote control).
>>>
>>> How are these solutions connected? Does the captured applicati= on data
>>> go to the local room controller, or to an MCU in the middle of= the TP
>>> session? Or something else?
>>>
>>> [sb] They are normally connected to the local room telepresenc= e
>> system.
>>> Again, the people in the local room also need to see the
>> presentation,
>>
>>> so this is the most direct and also is the most bandwidth effi= cient
>>> approach. Another aspect is that the rooms can and are used pu= rely
>>> locally (with no remote systems at all), and presentations als= o need
>>> to work in that situation. BTW I think adding requirements for=
>> support
>>
>>> of multiple endpoints in the same room is an unwise path - thi= s is
>> not
>>
>>> SPLICES, and we have enough to do already. I agree with folks = who are
>>> saying it is out of scope[/sb]
>>>
>>>        Also, even though Webex allows remo= te control, in my
>>>        experience that feature is not used= as much as simple
>>>        presenting. I am
>>>        not saying it has no value, just th= at the most common case I
>> see
>>>        is a
>>>        simple presentation.
>>>
>>>    That is my experience as well. I wasn't thinking = about the
>>>    multi-user-control aspect.
>>>
>>>        Supporting the video cable still ha= s value, especially if you
>>>        have guest
>>>        presenter who does not have access = to your local network.
>> Most
>>>        of those
>>>        presenters are expecting to use a p= rojector, so they have the
>> cables
>>>        with them.
>>>
>>>    Surely. In this case, I presume the cable connect= s to the local
>> room
>>>    controller. If there are multiple cable connector= s (e.g. one at
>> each
>>>    seat) do they show up as multiple presentation st= reams? Or is
>> there
>>>    some sort of switch and floor control? If so, how= does one manage
>>>    the floor control?
>>>
>>>    [sb] Today there is one presenter at a time. With= multiple
>> cables,
>>>    there is usually a button at each spot, and if yo= u press it you
>>>    become the presenter (most recent request wins is= the policy).
>>>    Normal social courtesies handle conflict, so ther= e is no real
>> need
>>>    for formal floor control. This happens even in or= dinary webex
>>>    conferences - if someone grabs the ball when they= shouldn't have
>> it,
>>>    people say something and it gets resolved. Simila= rly, if someone
>>>    needs the ball. More precisely, the presenting vi= deo system holds
>>>    the token for the room. With H.239, the MCU (if t= here is one)
>> grants
>>>    it, using whatever policy it wants, and can revok= e it at any
>> time.
>>>    In point-to-point calls, the far end SHALL grant = it upon request,
>> so
>>>    in that case the turn-taking policy is mandated i= n the standard.
>>>    Multiple presenters in the same room is up to the= local room
>> policy
>>>    - there is no standard, and in my opinion none is= needed. The
>> token
>>>    remains owned by the local video system, it is al= lowed to present
>>>    whatever local source it wishes. [/sb]
>>>
>>>        My answer on application sharing fa= lling "out of favor"
>> related
>>>        specifically to vendor support for = standards-based
>> application
>>>        sharing
>>>        (T.120 in particular) - which I tho= ught was responsive to
>> your
>>>        original
>>>        question. Perhaps I misunderstood i= t. Anyway there were
>> several
>>>        reasons [and perhaps various viewpo= ints] on why T.120 was
>> dropped,
>>>        though I think it is probably not a= useful discussion for
>> this
>>>        list. I
>>>        know of no other standards-based pr= otocol for application
>> sharing.
>>>
>>>    I wasn't assuming there was, other than a pure vi= deo (and maybe
>>>    audio) stream interface. There are other fora for= that sort of
>>>    thing, but its my impression that this is largely= a world of
>>>    proprietary and defacto standards.
>>>
>>>        BTW, it is relatively common for we= b screen sharing to
>> co-exist
>>>        with the
>>>        videoconferencing presentation meth= ods. For instance, you can
>> have a
>>>        stand-alone webex conference, with = someone sharing their
>> laptop
>>>        screen
>>>        for the video participants.[/sb] >>>
>>>    I have done this. But it was cumbersome. IIRC, ge= tting the
>> sharing
>>>    to be visible in the room I was in required using= a video cable
>> in
>>>    addition to using webex sharing.
>>>
>>> [sb]With our equipment you could use the cable if you wished, = but it
>>> would not be required. Though generally speaking, people are u= sed to
>>> using projectors for presenting. Video systems are providing >> identical
>>
>>> interfaces, so they work the way people expect. For instance, = in IETF
>>> interim meetings the Webex screen is always presented locally,=
>>> frequently using a cable. The chairs may find that cumbersome,= but
>>> they certainly come into the meeting expecting to do it anyway= .[\sb]
>>>
>>>        Of course that is still somewhat cu= mbersome, but presumably
>> it
>> will
>>>        be improved over time. Its the UI f= or driving it that is
>> cumbersome,
>>>        not the output.
>>>
>>>        A key difference is that if the com= puter output is via video
>> cable
>>>        into the local room controller, the= n that is probably
>> responsible
>>>        for displaying it locally on a disp= lay in the room as well as
>>>        sending it to the remote end. If th= e users connect their
>> computers
>>>        directly to the MCU, then the captu= re will come to the room
>> just
>>>        like anything else from the MCU. >>>
>>>        [sb]The standard model for videocon= ferencing presentations is
>> a
>>>        token-controlled transmission. If y= ou don't have the token,
>> you are
>>>        receiving. The local equipment is a= lways responsible for
>> display.
>>>        Looping the presentation back throu= gh the MCU back to the
>>>        originating
>>>        site wastes bandwidth.
>>>
>>>        I don't know if web conferencing so= lutions do this
>> differently
>>>        or not.
>>>        I've always assumed that when I gra= b the webex "ball" I stop
>>>        receiving
>>>        desktop images. Certainly there is = no reason for the server
>> to
>> send
>>>        them back to me.[/sb]
>>>
>>>
>>>    Thanks,
>>>    Paul
>>>
>>
>> _______________________________________________
>> clue mailing list
>> clue@ietf.org
>> https://www.ietf.org/mailman/listinfo/clue
>
> _______________________________________________
> clue mailing list
> clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue

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


--_000_EADCEEE0AE4A7F46BD61061696794D9819E67669szxeml536mbx_-- From stephen.botzko@gmail.com Fri May 4 01:26:37 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADB5021F8747 for ; Fri, 4 May 2012 01:26:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.356 X-Spam-Level: X-Spam-Status: No, score=-3.356 tagged_above=-999 required=5 tests=[AWL=0.242, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ng1OmegDKdfx for ; Fri, 4 May 2012 01:26:35 -0700 (PDT) Received: from mail-pz0-f53.google.com (mail-pz0-f53.google.com [209.85.210.53]) by ietfa.amsl.com (Postfix) with ESMTP id 8A6FB21F8746 for ; Fri, 4 May 2012 01:26:35 -0700 (PDT) Received: by dadg9 with SMTP id g9so3046196dad.26 for ; Fri, 04 May 2012 01:26:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=I/2FGwNmNjfm5QNrwlJEgIyFBEzB3VyNbwmhdYgu9Ec=; b=hxXRW+lFF5zCgNlVkOWuMQDUzJ2pCLHYkPl1Q3dL8A9K2UA+J9ATLc+s0X9hKRuizV /oRUivwabtXnHNIzIRGU3YaMHK28tN/hMSrfHzHFaJvUFOEaTNJ/e7Eax4xPBKTFfFcJ dMOHzpIVS0U6W3/xh+ma6xYT40FyeP2ji0Pybc+f02rQVB0wMbUi9+G/09Nzpvr2rpvL S/ab6kgK4S9eLvmCP17LKUuM1B0I40qZpnI7YfUq+QKzAWZpYRjDHhtrgQELzP5GFsh+ 7fb08wYE8VQZnmLyeC8v5mx+FCl0ybK+5aQnwVKdbpOlfUTX6hu0msJ1eBM4Pg9Tl6hF YZQg== MIME-Version: 1.0 Received: by 10.68.227.134 with SMTP id sa6mr15974032pbc.101.1336119995101; Fri, 04 May 2012 01:26:35 -0700 (PDT) Received: by 10.68.239.228 with HTTP; Fri, 4 May 2012 01:26:34 -0700 (PDT) In-Reply-To: References: <4F997E6B.7070501@alum.mit.edu> <4F9B0D81.4040608@alum.mit.edu> <4F9EC454.3060605@alum.mit.edu> <05DD269BD82AA549BC4B2619BBAC466A0109F228@XMB-AMS-206.cisco.com> <4FA15144.9030307@alum.mit.edu> <05DD269BD82AA549BC4B2619BBAC466A0109F407@XMB-AMS-206.cisco.com> <4fa295be.0852b40a.771f.1804@mx.google.com> Date: Fri, 4 May 2012 10:26:34 +0200 Message-ID: From: Stephen Botzko To: Brian Rosen Content-Type: multipart/alternative; boundary=047d7b2ee39baf71b704bf31ad1e Cc: CLUE , "Johan Ludvig Nielsen \(johaniel\)" Subject: Re: [clue] ways of managing presentations in telepresence sessions X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 04 May 2012 08:26:37 -0000 --047d7b2ee39baf71b704bf31ad1e Content-Type: text/plain; charset=ISO-8859-1 Of course it is a real problem, it happens every day. The exact same issue occurs with mixes of speaker phones, mobile phones, PCs, and traditional video conferencing all the time. The problem is not unique to multi-stream endpoints, and is not made worse by CLUE. The only solutions that work are to (a) route the presentation audio output into an telepresence room audio input, instead of using built-in speakers in the presentation system and (b) disconnect the presentation audio output and (c) mute the presentation audio output. These solutions are physical, and do not involve the normal signaling layers we develop in the IETF. Detection of the echo/feedback path can in principle be done in the media plane, though it does add complexity to each endpoint. Detecting it through signaling is problematic, since the various devices involved often use different protocols, and therefore have no common knowledge of what audio conference they are in. There are also scenarios where the echo/feedback path occurs with *independent* audio bridges (or no bridges at all). And there is no ability to identify that the devices are in the same location and that they both have open microphones or speakers. Eliminating the echo/feedback automatically is also challenging, since you need to identify the best devices to mute, and create a mechanism which can block the problematic signaling path(s). Such a mechanism can also be exploited to launch a denial of service attack. In my view this is clearly not a CLUE issue, and I don't see much hope for a workable signaling solution no matter where it is done. Stephen Botzko On Thu, May 3, 2012 at 11:17 PM, Brian Rosen wrote: > Because it's not a common problem, and there is no right way to do it. > > Having the telepresence audio/video on one system and the presentation > system on another is probably more common that having them on the same > system. > > Brian > > On May 3, 2012, at 4:40 PM, Stephen Botzko wrote: > > I have two separate speakerphones from two vendors in one room calling > into the same audio conference. They interact in a way that utterly fails > to deliver usable audio to phones in other locations. We don't have > mechanisms in SIP to represent this or prevent the bad behaviour. > > This is a problem for the IETF because???? > > Stephen Botzko > > On Thu, May 3, 2012 at 6:18 PM, Brian Rosen wrote: > >> I go back to what I see is the fundamental issue: >> >> You have two separate systems from two vendors in one room. They >> interact in a way that is important to other rooms. We don't have >> mechanisms to represent this. >> >> Brian >> >> On May 3, 2012, at 10:25 AM, Roni Even wrote: >> >> > Hi, >> > See inline >> > Roni >> > >> >> -----Original Message----- >> >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf >> Of >> >> Johan Ludvig Nielsen (johaniel) >> >> Sent: Thursday, May 03, 2012 4:02 PM >> >> To: Paul Kyzivat >> >> Cc: CLUE >> >> Subject: Re: [clue] ways of managing presentations in telepresence >> >> sessions >> >> >> >> Sorry for being unclear. I am commenting on the implied option of >> >> rendering presentation on a separate system, either on one or several >> >> computers or a dedicated endpoint separate from the telepresence system >> >> in the room. >> >> >> >> My main point is that all audio belonging to a conference and being >> >> played back in a room must be controlled by or at least known to the >> >> audio processing unit sending audio _from_ that room. This is to avoid >> >> echo or multi-path problems. >> >> >> >> One example of such a problem is if a presentation in the form of a >> >> movie with a soundtrack is played back on a computer separate from the >> >> telepresence system in the room. The microphone system in the room will >> >> pick up the sound from the computer's loudspeakers and happily transmit >> >> that as voice into the conference. The presentation audio is then >> >> delivered to other sites through two different paths with different >> >> delays, one of them with poor quality. >> > >> > This is not a problem of the current protocols, you can send two audio >> > streams in SIP and assign a different content attribute to each of >> them. The >> > issue of the local echo of the movie sound to the people audio is a >> local >> > system issue and not a standard issue. As for handling two audio streams >> > this will require a definition like H.239 for this case in order to >> achieve >> > interoperability. >> >> >> >> The other (and totally separate) point I am making is that with CLUE we >> >> will have the ability to send presentation audio as a separate stream, >> >> and that we are happy about that. Today locally input presentation >> >> audio is most often mixed with the mic signal and sent in the main >> >> audio stream (which can be stereo). There is no H.239 equivalent for >> >> audio. >> > >> > Sending two separate audio is not a CLUE feature, it can be done by >> offering >> > two audio RTP sessions for example. >> > >> >> >> >> Regards >> >> Johan >> >> >> >> >> >> >> >> -----Original Message----- >> >> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >> >> Sent: 2. mai 2012 17:23 >> >> To: Johan Ludvig Nielsen (johaniel) >> >> Cc: Stephen Botzko; CLUE >> >> Subject: Re: [clue] ways of managing presentations in telepresence >> >> sessions >> >> >> >> On 5/2/12 8:06 AM, Johan Ludvig Nielsen (johaniel) wrote: >> >>> I just want to remind you all that presentation often means video >> >>> _and_ audio, for instance a movie clip with a stereo soundtrack. >> >>> Sometimes presentation means only audio. Hook up your favourite >> >> device >> >> >> >>> and share a music clip or an interesting recording. >> >>> >> >>> Any presentation audio played back locally must be controlled by, or >> >>> at least be exactly (in sample sync) known to, the local telepresence >> >>> system controller. A totally separate endpoint for presentation will >> >>> therefore cause some practical problems. >> >>> >> >>> By the way, one very useful effect of CLUE is the ability for >> >>> receiving endpoints to distinguish between audio from live talking >> >>> sources and presentations/recordings. >> >> >> >> I'm not sure I understand the point you are making. >> >> Certainly it is true that a presentation may consist of audio and >> >> video. >> >> But its not just presentations that can contain paired audio and video. >> >> When we have many audio and video captures, there could be several >> >> pairs. >> >> >> >> RFC3388 provides a way (a=mid:ls) to indicate when lip sync is >> >> required. >> >> Do we need more than that? Should advertisements indicate desirable >> >> audio/video pairings so that selection can take that into account? >> >> >> >> Thanks, >> >> Paul >> >> >> >>> Johan >> >>> >> >>> *From:*clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On >> >> Behalf >> >> >> >>> Of *Stephen Botzko >> >>> *Sent:* 1. mai 2012 09:11 >> >>> *To:* Paul Kyzivat >> >>> *Cc:* CLUE >> >>> *Subject:* Re: [clue] ways of managing presentations in telepresence >> >>> sessions >> >>> >> >>> On Mon, Apr 30, 2012 at 12:56 PM, Paul Kyzivat > >>> > wrote: >> >>> >> >>> On 4/28/12 1:18 PM, Stephen Botzko wrote: >> >>> >> >>> [sb] As I mentioned above, the existing solutions usually include a >> >>> screen-scrape application, so you don't have to use a video cable. >> >>> This is essentially the same as using Webex for presenting (but not >> >>> remote control). >> >>> >> >>> How are these solutions connected? Does the captured application data >> >>> go to the local room controller, or to an MCU in the middle of the TP >> >>> session? Or something else? >> >>> >> >>> [sb] They are normally connected to the local room telepresence >> >> system. >> >>> Again, the people in the local room also need to see the >> >> presentation, >> >> >> >>> so this is the most direct and also is the most bandwidth efficient >> >>> approach. Another aspect is that the rooms can and are used purely >> >>> locally (with no remote systems at all), and presentations also need >> >>> to work in that situation. BTW I think adding requirements for >> >> support >> >> >> >>> of multiple endpoints in the same room is an unwise path - this is >> >> not >> >> >> >>> SPLICES, and we have enough to do already. I agree with folks who are >> >>> saying it is out of scope[/sb] >> >>> >> >>> Also, even though Webex allows remote control, in my >> >>> experience that feature is not used as much as simple >> >>> presenting. I am >> >>> not saying it has no value, just that the most common case I >> >> see >> >>> is a >> >>> simple presentation. >> >>> >> >>> That is my experience as well. I wasn't thinking about the >> >>> multi-user-control aspect. >> >>> >> >>> Supporting the video cable still has value, especially if you >> >>> have guest >> >>> presenter who does not have access to your local network. >> >> Most >> >>> of those >> >>> presenters are expecting to use a projector, so they have the >> >> cables >> >>> with them. >> >>> >> >>> Surely. In this case, I presume the cable connects to the local >> >> room >> >>> controller. If there are multiple cable connectors (e.g. one at >> >> each >> >>> seat) do they show up as multiple presentation streams? Or is >> >> there >> >>> some sort of switch and floor control? If so, how does one manage >> >>> the floor control? >> >>> >> >>> [sb] Today there is one presenter at a time. With multiple >> >> cables, >> >>> there is usually a button at each spot, and if you press it you >> >>> become the presenter (most recent request wins is the policy). >> >>> Normal social courtesies handle conflict, so there is no real >> >> need >> >>> for formal floor control. This happens even in ordinary webex >> >>> conferences - if someone grabs the ball when they shouldn't have >> >> it, >> >>> people say something and it gets resolved. Similarly, if someone >> >>> needs the ball. More precisely, the presenting video system holds >> >>> the token for the room. With H.239, the MCU (if there is one) >> >> grants >> >>> it, using whatever policy it wants, and can revoke it at any >> >> time. >> >>> In point-to-point calls, the far end SHALL grant it upon request, >> >> so >> >>> in that case the turn-taking policy is mandated in the standard. >> >>> Multiple presenters in the same room is up to the local room >> >> policy >> >>> - there is no standard, and in my opinion none is needed. The >> >> token >> >>> remains owned by the local video system, it is allowed to present >> >>> whatever local source it wishes. [/sb] >> >>> >> >>> My answer on application sharing falling "out of favor" >> >> related >> >>> specifically to vendor support for standards-based >> >> application >> >>> sharing >> >>> (T.120 in particular) - which I thought was responsive to >> >> your >> >>> original >> >>> question. Perhaps I misunderstood it. Anyway there were >> >> several >> >>> reasons [and perhaps various viewpoints] on why T.120 was >> >> dropped, >> >>> though I think it is probably not a useful discussion for >> >> this >> >>> list. I >> >>> know of no other standards-based protocol for application >> >> sharing. >> >>> >> >>> I wasn't assuming there was, other than a pure video (and maybe >> >>> audio) stream interface. There are other fora for that sort of >> >>> thing, but its my impression that this is largely a world of >> >>> proprietary and defacto standards. >> >>> >> >>> BTW, it is relatively common for web screen sharing to >> >> co-exist >> >>> with the >> >>> videoconferencing presentation methods. For instance, you can >> >> have a >> >>> stand-alone webex conference, with someone sharing their >> >> laptop >> >>> screen >> >>> for the video participants.[/sb] >> >>> >> >>> I have done this. But it was cumbersome. IIRC, getting the >> >> sharing >> >>> to be visible in the room I was in required using a video cable >> >> in >> >>> addition to using webex sharing. >> >>> >> >>> [sb]With our equipment you could use the cable if you wished, but it >> >>> would not be required. Though generally speaking, people are used to >> >>> using projectors for presenting. Video systems are providing >> >> identical >> >> >> >>> interfaces, so they work the way people expect. For instance, in IETF >> >>> interim meetings the Webex screen is always presented locally, >> >>> frequently using a cable. The chairs may find that cumbersome, but >> >>> they certainly come into the meeting expecting to do it anyway.[\sb] >> >>> >> >>> Of course that is still somewhat cumbersome, but presumably >> >> it >> >> will >> >>> be improved over time. Its the UI for driving it that is >> >> cumbersome, >> >>> not the output. >> >>> >> >>> A key difference is that if the computer output is via video >> >> cable >> >>> into the local room controller, then that is probably >> >> responsible >> >>> for displaying it locally on a display in the room as well as >> >>> sending it to the remote end. If the users connect their >> >> computers >> >>> directly to the MCU, then the capture will come to the room >> >> just >> >>> like anything else from the MCU. >> >>> >> >>> [sb]The standard model for videoconferencing presentations is >> >> a >> >>> token-controlled transmission. If you don't have the token, >> >> you are >> >>> receiving. The local equipment is always responsible for >> >> display. >> >>> Looping the presentation back through the MCU back to the >> >>> originating >> >>> site wastes bandwidth. >> >>> >> >>> I don't know if web conferencing solutions do this >> >> differently >> >>> or not. >> >>> I've always assumed that when I grab the webex "ball" I stop >> >>> receiving >> >>> desktop images. Certainly there is no reason for the server >> >> to >> >> send >> >>> them back to me.[/sb] >> >>> >> >>> >> >>> Thanks, >> >>> Paul >> >>> >> >> >> >> _______________________________________________ >> >> clue mailing list >> >> clue@ietf.org >> >> https://www.ietf.org/mailman/listinfo/clue >> > >> > _______________________________________________ >> > clue mailing list >> > clue@ietf.org >> > https://www.ietf.org/mailman/listinfo/clue >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> > > > --047d7b2ee39baf71b704bf31ad1e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Of course it is a real problem, it happens every day. The exact same issue = occurs with mixes of speaker phones, mobile phones, PCs,=A0 and traditional video conferencing all the time.=A0 The problem is= not unique to multi-stream endpoints, and is not made worse by CLUE.=A0
The only solutions that work are to (a) route the presentation audio = output into an telepresence room audio input, instead of using built-in spe= akers in the presentation system and (b) disconnect the presentation audio = output and (c) mute the presentation audio output.=A0 These solutions are p= hysical, and do not involve the normal signaling layers we develop in the I= ETF.

Detection of the echo/feedback path can in principle be done in the med= ia plane, though it does add complexity to each endpoint.

Detecting = it through signaling is problematic, since the various devices involved oft= en use different protocols, and therefore have no common knowledge of what = audio conference they are in.=A0 There are also scenarios where the echo/fe= edback path occurs with independent audio bridges (or no bridges at = all).=A0 And there is no ability to identify that the devices are in the sa= me location and that they both have open microphones or speakers.

Eliminating the echo/feedback automatically is also challenging, since = you need to identify the best devices to mute, and create a mechanism which= can block the problematic signaling path(s).=A0 Such a mechanism can also = be exploited to launch a denial of service attack.

In my view this is clearly not a CLUE issue, and I don't see much h= ope for a workable signaling solution no matter where it is done.

S= tephen Botzko

On Thu, May 3, 2012 at 11:1= 7 PM, Brian Rosen <br@brianrosen.net> wrote:
Because = it's not a common problem, and there is no right way to do it.

=
Having the telepresence audio/video on one system and the presentation= system on another is probably more common that having them on the same sys= tem.

Brian

On May 3= , 2012, at 4:40 PM, Stephen Botzko wrote:

I have two separate speakerphones from two vendors in one room calling in= to the same audio conference.=A0 They interact in a way that utterly fails = to deliver usable audio to phones in other locations.=A0 We don't have = mechanisms in SIP to represent this or prevent the bad behaviour.=A0

This is a problem for the IETF because????

Stephen Botzko
On Thu, May 3, 2012 at 6:18 PM, Brian Rosen <b= r@brianrosen.net> wrote:
I go back to what I see is the fundamental i= ssue:

You have two separate systems from two vendors in one room. =A0They interac= t in a way that is important to other rooms. =A0We don't have mechanism= s to represent this.

Brian

On May 3, 2012, at 10:25 AM, Roni Even wrote:

> Hi,
> See inline
> Roni
>
>> -----Original Message-----
>> From: c= lue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of
>> Johan Ludvig Nielsen (johaniel)
>> Sent: Thursday, May 03, 2012 4:02 PM
>> To: Paul Kyzivat
>> Cc: CLUE
>> Subject: Re: [clue] ways of managing presentations in telepresence=
>> sessions
>>
>> Sorry for being unclear. I am commenting on the implied option of<= br> >> rendering presentation on a separate system, either on one or seve= ral
>> computers or a dedicated endpoint separate from the telepresence s= ystem
>> in the room.
>>
>> My main point is that all audio belonging to a conference and bein= g
>> played back in a room must be controlled by or at least known to t= he
>> audio processing unit sending audio _from_ that room. This is to a= void
>> echo or multi-path problems.
>>
>> One example of such a problem is if a presentation in the form of = a
>> movie with a soundtrack is played back on a computer separate from= the
>> telepresence system in the room. The microphone system in the room= will
>> pick up the sound from the computer's loudspeakers and happily= transmit
>> that as voice into the conference. The presentation audio is then<= br> >> delivered to other sites through two different paths with differen= t
>> delays, one of them with poor quality.
>
> This is not a problem of the current protocols, you can send two audio=
> streams in SIP and assign a different content attribute to each of the= m. The
> issue of the local echo of the movie sound to the people audio is a lo= cal
> system issue and not a standard issue. As for handling two audio strea= ms
> this will require a definition like H.239 for this case in order to ac= hieve
> interoperability.
>>
>> The other (and totally separate) point I am making is that with CL= UE we
>> will have the ability to send presentation audio as a separate str= eam,
>> and that we are happy about that. Today locally input presentation=
>> audio is most often mixed with the mic signal and sent in the main=
>> audio stream (which can be stereo). There is no H.239 equivalent f= or
>> audio.
>
> Sending two separate audio is not a CLUE feature, it can be done by of= fering
> two audio RTP sessions for example.
>
>>
>> Regards
>> Johan
>>
>>
>>
>> -----Original Message-----
>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]
>> Sent: 2. mai 2012 17:23
>> To: Johan Ludvig Nielsen (johaniel)
>> Cc: Stephen Botzko; CLUE
>> Subject: Re: [clue] ways of managing presentations in telepresence=
>> sessions
>>
>> On 5/2/12 8:06 AM, Johan Ludvig Nielsen (johaniel) wrote:
>>> I just want to remind you all that presentation often means vi= deo
>>> _and_ audio, for instance a movie clip with a stereo soundtrac= k.
>>> Sometimes presentation means only audio. Hook up your favourit= e
>> device
>>
>>> and share a music clip or an interesting recording.
>>>
>>> Any presentation audio played back locally must be controlled = by, or
>>> at least be exactly (in sample sync) known to, the local telep= resence
>>> system controller. A totally separate endpoint for presentatio= n will
>>> therefore cause some practical problems.
>>>
>>> By the way, one very useful effect of CLUE is the ability for<= br> >>> receiving endpoints to distinguish between audio from live tal= king
>>> sources and presentations/recordings.
>>
>> I'm not sure I understand the point you are making.
>> Certainly it is true that a presentation may consist of audio and<= br> >> video.
>> But its not just presentations that can contain paired audio and v= ideo.
>> When we have many audio and video captures, there could be several=
>> pairs.
>>
>> RFC3388 provides a way (a=3Dmid:ls) to indicate when lip sync is >> required.
>> Do we need more than that? Should advertisements indicate desirabl= e
>> audio/video pairings so that selection can take that into account?=
>>
>> =A0 =A0 =A0Thanks,
>> =A0 =A0 =A0Paul
>>
>>> Johan
>>>
>>> *From:*clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On
>> Behalf
>>
>>> Of *Stephen Botzko
>>> *Sent:* 1. mai 2012 09:11
>>> *To:* Paul Kyzivat
>>> *Cc:* CLUE
>>> *Subject:* Re: [clue] ways of managing presentations in telepr= esence
>>> sessions
>>>
>>> On Mon, Apr 30, 2012 at 12:56 PM, Paul Kyzivat <pkyzivat@alum.mit.edu >>> <mailto:pkyzivat@alum.mit.edu>> wrote:
>>>
>>> On 4/28/12 1:18 PM, Stephen Botzko wrote:
>>>
>>> [sb] As I mentioned above, the existing solutions usually incl= ude a
>>> screen-scrape application, so you don't have to use a vide= o cable.
>>> This is essentially the same as using Webex for presenting (bu= t not
>>> remote control).
>>>
>>> How are these solutions connected? Does the captured applicati= on data
>>> go to the local room controller, or to an MCU in the middle of= the TP
>>> session? Or something else?
>>>
>>> [sb] They are normally connected to the local room telepresenc= e
>> system.
>>> Again, the people in the local room also need to see the
>> presentation,
>>
>>> so this is the most direct and also is the most bandwidth effi= cient
>>> approach. Another aspect is that the rooms can and are used pu= rely
>>> locally (with no remote systems at all), and presentations als= o need
>>> to work in that situation. BTW I think adding requirements for=
>> support
>>
>>> of multiple endpoints in the same room is an unwise path - thi= s is
>> not
>>
>>> SPLICES, and we have enough to do already. I agree with folks = who are
>>> saying it is out of scope[/sb]
>>>
>>> =A0 =A0 =A0 =A0Also, even though Webex allows remote control, = in my
>>> =A0 =A0 =A0 =A0experience that feature is not used as much as = simple
>>> =A0 =A0 =A0 =A0presenting. I am
>>> =A0 =A0 =A0 =A0not saying it has no value, just that the most = common case I
>> see
>>> =A0 =A0 =A0 =A0is a
>>> =A0 =A0 =A0 =A0simple presentation.
>>>
>>> =A0 =A0That is my experience as well. I wasn't thinking ab= out the
>>> =A0 =A0multi-user-control aspect.
>>>
>>> =A0 =A0 =A0 =A0Supporting the video cable still has value, esp= ecially if you
>>> =A0 =A0 =A0 =A0have guest
>>> =A0 =A0 =A0 =A0presenter who does not have access to your loca= l network.
>> Most
>>> =A0 =A0 =A0 =A0of those
>>> =A0 =A0 =A0 =A0presenters are expecting to use a projector, so= they have the
>> cables
>>> =A0 =A0 =A0 =A0with them.
>>>
>>> =A0 =A0Surely. In this case, I presume the cable connects to t= he local
>> room
>>> =A0 =A0controller. If there are multiple cable connectors (e.g= . one at
>> each
>>> =A0 =A0seat) do they show up as multiple presentation streams?= Or is
>> there
>>> =A0 =A0some sort of switch and floor control? If so, how does = one manage
>>> =A0 =A0the floor control?
>>>
>>> =A0 =A0[sb] Today there is one presenter at a time. With multi= ple
>> cables,
>>> =A0 =A0there is usually a button at each spot, and if you pres= s it you
>>> =A0 =A0become the presenter (most recent request wins is the p= olicy).
>>> =A0 =A0Normal social courtesies handle conflict, so there is n= o real
>> need
>>> =A0 =A0for formal floor control. This happens even in ordinary= webex
>>> =A0 =A0conferences - if someone grabs the ball when they shoul= dn't have
>> it,
>>> =A0 =A0people say something and it gets resolved. Similarly, i= f someone
>>> =A0 =A0needs the ball. More precisely, the presenting video sy= stem holds
>>> =A0 =A0the token for the room. With H.239, the MCU (if there i= s one)
>> grants
>>> =A0 =A0it, using whatever policy it wants, and can revoke it a= t any
>> time.
>>> =A0 =A0In point-to-point calls, the far end SHALL grant it upo= n request,
>> so
>>> =A0 =A0in that case the turn-taking policy is mandated in the = standard.
>>> =A0 =A0Multiple presenters in the same room is up to the local= room
>> policy
>>> =A0 =A0- there is no standard, and in my opinion none is neede= d. The
>> token
>>> =A0 =A0remains owned by the local video system, it is allowed = to present
>>> =A0 =A0whatever local source it wishes. [/sb]
>>>
>>> =A0 =A0 =A0 =A0My answer on application sharing falling "= out of favor"
>> related
>>> =A0 =A0 =A0 =A0specifically to vendor support for standards-ba= sed
>> application
>>> =A0 =A0 =A0 =A0sharing
>>> =A0 =A0 =A0 =A0(T.120 in particular) - which I thought was res= ponsive to
>> your
>>> =A0 =A0 =A0 =A0original
>>> =A0 =A0 =A0 =A0question. Perhaps I misunderstood it. Anyway th= ere were
>> several
>>> =A0 =A0 =A0 =A0reasons [and perhaps various viewpoints] on why= T.120 was
>> dropped,
>>> =A0 =A0 =A0 =A0though I think it is probably not a useful disc= ussion for
>> this
>>> =A0 =A0 =A0 =A0list. I
>>> =A0 =A0 =A0 =A0know of no other standards-based protocol for a= pplication
>> sharing.
>>>
>>> =A0 =A0I wasn't assuming there was, other than a pure vide= o (and maybe
>>> =A0 =A0audio) stream interface. There are other fora for that = sort of
>>> =A0 =A0thing, but its my impression that this is largely a wor= ld of
>>> =A0 =A0proprietary and defacto standards.
>>>
>>> =A0 =A0 =A0 =A0BTW, it is relatively common for web screen sha= ring to
>> co-exist
>>> =A0 =A0 =A0 =A0with the
>>> =A0 =A0 =A0 =A0videoconferencing presentation methods. For ins= tance, you can
>> have a
>>> =A0 =A0 =A0 =A0stand-alone webex conference, with someone shar= ing their
>> laptop
>>> =A0 =A0 =A0 =A0screen
>>> =A0 =A0 =A0 =A0for the video participants.[/sb]
>>>
>>> =A0 =A0I have done this. But it was cumbersome. IIRC, getting = the
>> sharing
>>> =A0 =A0to be visible in the room I was in required using a vid= eo cable
>> in
>>> =A0 =A0addition to using webex sharing.
>>>
>>> [sb]With our equipment you could use the cable if you wished, = but it
>>> would not be required. Though generally speaking, people are u= sed to
>>> using projectors for presenting. Video systems are providing >> identical
>>
>>> interfaces, so they work the way people expect. For instance, = in IETF
>>> interim meetings the Webex screen is always presented locally,=
>>> frequently using a cable. The chairs may find that cumbersome,= but
>>> they certainly come into the meeting expecting to do it anyway= .[\sb]
>>>
>>> =A0 =A0 =A0 =A0Of course that is still somewhat cumbersome, bu= t presumably
>> it
>> will
>>> =A0 =A0 =A0 =A0be improved over time. Its the UI for driving i= t that is
>> cumbersome,
>>> =A0 =A0 =A0 =A0not the output.
>>>
>>> =A0 =A0 =A0 =A0A key difference is that if the computer output= is via video
>> cable
>>> =A0 =A0 =A0 =A0into the local room controller, then that is pr= obably
>> responsible
>>> =A0 =A0 =A0 =A0for displaying it locally on a display in the r= oom as well as
>>> =A0 =A0 =A0 =A0sending it to the remote end. If the users conn= ect their
>> computers
>>> =A0 =A0 =A0 =A0directly to the MCU, then the capture will come= to the room
>> just
>>> =A0 =A0 =A0 =A0like anything else from the MCU.
>>>
>>> =A0 =A0 =A0 =A0[sb]The standard model for videoconferencing pr= esentations is
>> a
>>> =A0 =A0 =A0 =A0token-controlled transmission. If you don't= have the token,
>> you are
>>> =A0 =A0 =A0 =A0receiving. The local equipment is always respon= sible for
>> display.
>>> =A0 =A0 =A0 =A0Looping the presentation back through the MCU b= ack to the
>>> =A0 =A0 =A0 =A0originating
>>> =A0 =A0 =A0 =A0site wastes bandwidth.
>>>
>>> =A0 =A0 =A0 =A0I don't know if web conferencing solutions = do this
>> differently
>>> =A0 =A0 =A0 =A0or not.
>>> =A0 =A0 =A0 =A0I've always assumed that when I grab the we= bex "ball" I stop
>>> =A0 =A0 =A0 =A0receiving
>>> =A0 =A0 =A0 =A0desktop images. Certainly there is no reason fo= r the server
>> to
>> send
>>> =A0 =A0 =A0 =A0them back to me.[/sb]
>>>
>>>
>>> =A0 =A0Thanks,
>>> =A0 =A0Paul
>>>
>>
>> _______________________________________________
>> clue mailing list
>> clue@ietf.org
>> https://www.ietf.org/mailman/listinfo/clue
>
> _______________________________________________
> clue mailing list
> clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue

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



--047d7b2ee39baf71b704bf31ad1e-- From Mark.Duckworth@polycom.com Fri May 4 06:06:51 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 277DF21F85E4 for ; Fri, 4 May 2012 06:06:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PKKq09a7qbvt for ; Fri, 4 May 2012 06:06:49 -0700 (PDT) Received: from Crpehubprd01.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id B17A521F85B6 for ; Fri, 4 May 2012 06:06:49 -0700 (PDT) Received: from Crpmboxprd01.polycom.com ([fe80::ad68:5a0:c919:66b6]) by Crpehubprd01.polycom.com ([fe80::5efe:10.236.0.158%14]) with mapi; Fri, 4 May 2012 06:06:49 -0700 From: "Duckworth, Mark" To: CLUE Date: Fri, 4 May 2012 06:06:46 -0700 Thread-Topic: [clue] ways of managing presentations in telepresence sessions Thread-Index: Ac0pRbxRx5u8YNmATfKEamRQsm1YaQAsDHBQ Message-ID: <44C6B6B2D0CF424AA90B6055548D7A6102FD51ED1C@CRPMBOXPRD01.polycom.com> References: <4F997E6B.7070501@alum.mit.edu><4F9B0D81.4040608@alum.mit.edu><4F9EC454.3060605@alum.mit.edu> <05DD269BD82AA549BC4B2619BBAC466A0109F228@XMB-AMS-206.cisco.com> <4FA15144.9030307@alum.mit.edu> <05DD269BD82AA549BC4B2619BBAC466A0109F407@XMB-AMS-206.cisco.com> <4FA2AB5D.7050205@alum.mit.edu> In-Reply-To: <4FA2AB5D.7050205@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [clue] ways of managing presentations in telepresence sessions X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 04 May 2012 13:06:51 -0000 Paul asked: " when selecting which capture scene entries and captures to receive, th= e recipient will be able to identify audio/video pairs so that they can be select= ed as a pair?" Yes, this is one of the functions of capture scenes. If the provider is ad= vertising an audio/video pair, then the provider puts the video in a captur= e scene entry and the audio in another capture scene entry and puts both th= ese capture scene entries into the same capture scene. So the consumer kno= ws the audio and video are part of the same capture scene, so the consumer = can select them both and render them together. Mark > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Paul Kyzivat > Sent: Thursday, May 03, 2012 11:59 AM > To: Johan Ludvig Nielsen (johaniel) > Cc: CLUE > Subject: Re: [clue] ways of managing presentations in telepresence sessio= ns >=20 > On 5/3/12 9:02 AM, Johan Ludvig Nielsen (johaniel) wrote: > > Sorry for being unclear. I am commenting on the implied option of > > rendering presentation on a separate system, either on one or several > > computers or a dedicated endpoint separate from the telepresence > > system in the room. > > > > My main point is that all audio belonging to a conference and being > > played back in a room must be controlled by or at least known to the > > audio processing unit sending audio _from_ that room. This is to avoid > > echo or multi-path problems. > > > > One example of such a problem is if a presentation in the form of a > > movie with a soundtrack is played back on a computer separate from the > > telepresence system in the room. The microphone system in the room > > will pick up the sound from the computer's loudspeakers and happily > > transmit that as voice into the conference. The presentation audio is > > then delivered to other sites through two different paths with > > different delays, one of them with poor quality. >=20 > OK, this is a good point. > So a participant sitting in a TP room could connect his computer to the M= CU > for the TP session as an independent endpoint and receive and play out > video captures without trouble. But if it receives and plays out audio th= ere > might be trouble. If it were just presentation audio, and it was played b= ack to > headphones it might be ok. But if played back via speakers it could be a > problem. >=20 > I suppose that is something that would have to be considered pilot error > rather than a defect in CLUE. >=20 > > The other (and totally separate) point I am making is that with CLUE > > we will have the ability to send presentation audio as a separate > > stream, and that we are happy about that. Today locally input > > presentation audio is most often mixed with the mic signal and sent in > > the main audio stream (which can be stereo). There is no H.239 equivale= nt > for audio. >=20 > So yes, we have that capability. Do we have sufficient description of it = to > make it fully usable? In particular, do we have enough so that, when > selecting which capture scene entries and captures to receive, the recipi= ent > will be able to identify audio/video pairs so that they can be selected a= s a > pair? >=20 > Thanks, > Paul >=20 > > Regards > > Johan > > > > > > > > -----Original Message----- > > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > > Sent: 2. mai 2012 17:23 > > To: Johan Ludvig Nielsen (johaniel) > > Cc: Stephen Botzko; CLUE > > Subject: Re: [clue] ways of managing presentations in telepresence > > sessions > > > > On 5/2/12 8:06 AM, Johan Ludvig Nielsen (johaniel) wrote: > >> I just want to remind you all that presentation often means video > >> _and_ audio, for instance a movie clip with a stereo soundtrack. > >> Sometimes presentation means only audio. Hook up your favourite > >> device > > > >> and share a music clip or an interesting recording. > >> > >> Any presentation audio played back locally must be controlled by, or > >> at least be exactly (in sample sync) known to, the local telepresence > >> system controller. A totally separate endpoint for presentation will > >> therefore cause some practical problems. > >> > >> By the way, one very useful effect of CLUE is the ability for > >> receiving endpoints to distinguish between audio from live talking > >> sources and presentations/recordings. > > > > I'm not sure I understand the point you are making. > > Certainly it is true that a presentation may consist of audio and video= . > > But its not just presentations that can contain paired audio and video. > > When we have many audio and video captures, there could be several > > pairs. > > > > RFC3388 provides a way (a=3Dmid:ls) to indicate when lip sync is requir= ed. > > Do we need more than that? Should advertisements indicate desirable > > audio/video pairings so that selection can take that into account? > > > > Thanks, > > Paul > > > >> Johan > >> > >> *From:*clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On > >> Behalf > > > >> Of *Stephen Botzko > >> *Sent:* 1. mai 2012 09:11 > >> *To:* Paul Kyzivat > >> *Cc:* CLUE > >> *Subject:* Re: [clue] ways of managing presentations in telepresence > >> sessions > >> > >> On Mon, Apr 30, 2012 at 12:56 PM, Paul Kyzivat >> > wrote: > >> > >> On 4/28/12 1:18 PM, Stephen Botzko wrote: > >> > >> [sb] As I mentioned above, the existing solutions usually include a > >> screen-scrape application, so you don't have to use a video cable. > >> This is essentially the same as using Webex for presenting (but not > >> remote control). > >> > >> How are these solutions connected? Does the captured application data > >> go to the local room controller, or to an MCU in the middle of the TP > >> session? Or something else? > >> > >> [sb] They are normally connected to the local room telepresence > > system. > >> Again, the people in the local room also need to see the > >> presentation, > > > >> so this is the most direct and also is the most bandwidth efficient > >> approach. Another aspect is that the rooms can and are used purely > >> locally (with no remote systems at all), and presentations also need > >> to work in that situation. BTW I think adding requirements for > >> support > > > >> of multiple endpoints in the same room is an unwise path - this is > >> not > > > >> SPLICES, and we have enough to do already. I agree with folks who are > >> saying it is out of scope[/sb] > >> > >> Also, even though Webex allows remote control, in my > >> experience that feature is not used as much as simple > >> presenting. I am > >> not saying it has no value, just that the most common case I > > see > >> is a > >> simple presentation. > >> > >> That is my experience as well. I wasn't thinking about the > >> multi-user-control aspect. > >> > >> Supporting the video cable still has value, especially if you > >> have guest > >> presenter who does not have access to your local network. Mos= t > >> of those > >> presenters are expecting to use a projector, so they have > >> the > > cables > >> with them. > >> > >> Surely. In this case, I presume the cable connects to the local > > room > >> controller. If there are multiple cable connectors (e.g. one at > > each > >> seat) do they show up as multiple presentation streams? Or is > > there > >> some sort of switch and floor control? If so, how does one manage > >> the floor control? > >> > >> [sb] Today there is one presenter at a time. With multiple cables= , > >> there is usually a button at each spot, and if you press it you > >> become the presenter (most recent request wins is the policy). > >> Normal social courtesies handle conflict, so there is no real nee= d > >> for formal floor control. This happens even in ordinary webex > >> conferences - if someone grabs the ball when they shouldn't have > > it, > >> people say something and it gets resolved. Similarly, if someone > >> needs the ball. More precisely, the presenting video system holds > >> the token for the room. With H.239, the MCU (if there is one) > > grants > >> it, using whatever policy it wants, and can revoke it at any time= . > >> In point-to-point calls, the far end SHALL grant it upon > >> request, > > so > >> in that case the turn-taking policy is mandated in the standard. > >> Multiple presenters in the same room is up to the local room > > policy > >> - there is no standard, and in my opinion none is needed. The > > token > >> remains owned by the local video system, it is allowed to present > >> whatever local source it wishes. [/sb] > >> > >> My answer on application sharing falling "out of favor" > > related > >> specifically to vendor support for standards-based applicatio= n > >> sharing > >> (T.120 in particular) - which I thought was responsive to you= r > >> original > >> question. Perhaps I misunderstood it. Anyway there were > > several > >> reasons [and perhaps various viewpoints] on why T.120 was > > dropped, > >> though I think it is probably not a useful discussion for thi= s > >> list. I > >> know of no other standards-based protocol for application > > sharing. > >> > >> I wasn't assuming there was, other than a pure video (and maybe > >> audio) stream interface. There are other fora for that sort of > >> thing, but its my impression that this is largely a world of > >> proprietary and defacto standards. > >> > >> BTW, it is relatively common for web screen sharing to > > co-exist > >> with the > >> videoconferencing presentation methods. For instance, you > >> can > > have a > >> stand-alone webex conference, with someone sharing their > > laptop > >> screen > >> for the video participants.[/sb] > >> > >> I have done this. But it was cumbersome. IIRC, getting the sharin= g > >> to be visible in the room I was in required using a video cable i= n > >> addition to using webex sharing. > >> > >> [sb]With our equipment you could use the cable if you wished, but it > >> would not be required. Though generally speaking, people are used to > >> using projectors for presenting. Video systems are providing > >> identical > > > >> interfaces, so they work the way people expect. For instance, in IETF > >> interim meetings the Webex screen is always presented locally, > >> frequently using a cable. The chairs may find that cumbersome, but > >> they certainly come into the meeting expecting to do it anyway.[\sb] > >> > >> Of course that is still somewhat cumbersome, but presumably > >> it > > will > >> be improved over time. Its the UI for driving it that is > > cumbersome, > >> not the output. > >> > >> A key difference is that if the computer output is via video > > cable > >> into the local room controller, then that is probably > > responsible > >> for displaying it locally on a display in the room as well as > >> sending it to the remote end. If the users connect their > > computers > >> directly to the MCU, then the capture will come to the room > > just > >> like anything else from the MCU. > >> > >> [sb]The standard model for videoconferencing presentations > >> is > > a > >> token-controlled transmission. If you don't have the token, > > you are > >> receiving. The local equipment is always responsible for > > display. > >> Looping the presentation back through the MCU back to the > >> originating > >> site wastes bandwidth. > >> > >> I don't know if web conferencing solutions do this differentl= y > >> or not. > >> I've always assumed that when I grab the webex "ball" I stop > >> receiving > >> desktop images. Certainly there is no reason for the server > >> to > > send > >> them back to me.[/sb] > >> > >> > >> Thanks, > >> Paul > >> > > > > >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From magnus.westerlund@ericsson.com Fri May 4 06:14:58 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DE5821F864D for ; Fri, 4 May 2012 06:14:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.709 X-Spam-Level: X-Spam-Status: No, score=-105.709 tagged_above=-999 required=5 tests=[AWL=-0.330, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, SARE_MLH_Stock1=0.87, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q8jFRVu+p+hF for ; Fri, 4 May 2012 06:14:58 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 224C521F85E1 for ; Fri, 4 May 2012 06:14:57 -0700 (PDT) X-AuditID: c1b4fb30-b7b07ae000006839-70-4fa3d6503192 Authentication-Results: mailgw7.ericsson.se x-tls.subject="/CN=esessmw0191"; auth=fail (cipher=AES128-SHA) Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client CN "esessmw0191", Issuer "esessmw0191" (not verified)) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id B3.51.26681.156D3AF4; Fri, 4 May 2012 15:14:57 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.213.0; Fri, 4 May 2012 15:14:56 +0200 Message-ID: <4FA3D650.4060509@ericsson.com> Date: Fri, 4 May 2012 15:14:56 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: CLUE X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: [clue] Host and Local Information for Stockholm Interim X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 04 May 2012 13:14:58 -0000 WG, We at Ericsson hosting the meeting have now secured meeting rooms for the Interim. Therefore I can now announce that we will be holding the meeting in Kista. We also provide some more information about Kista, Hotels and travel in Stockholm. I would recommend that people secure a hotel booking as soon as possible as there is quite some pressure on hotel rooms during the period of the Interim. Please see for details: http://dl.dropbox.com/u/11888030/Practical%20Information%20for%20CLUE%20and%20WebRTC.htm Questions to the host about the location etc can be sent to me. Best Regards 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 pkyzivat@alum.mit.edu Fri May 4 06:26:58 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3C3321F8607 for ; Fri, 4 May 2012 06:26:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.488 X-Spam-Level: X-Spam-Status: No, score=-2.488 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id utn7TIiakunv for ; Fri, 4 May 2012 06:26:57 -0700 (PDT) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [76.96.59.228]) by ietfa.amsl.com (Postfix) with ESMTP id 24D0D21F85B5 for ; Fri, 4 May 2012 06:26:56 -0700 (PDT) Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta15.westchester.pa.mail.comcast.net with comcast id 5nuD1j0011swQuc5FpSwmh; Fri, 04 May 2012 13:26:56 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta15.westchester.pa.mail.comcast.net with comcast id 5pSw1j00g07duvL3bpSxR3; Fri, 04 May 2012 13:26:57 +0000 Message-ID: <4FA3D91F.7020008@alum.mit.edu> Date: Fri, 04 May 2012 09:26:55 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: clue@ietf.org References: <4F997E6B.7070501@alum.mit.edu><4F9B0D81.4040608@alum.mit.edu><4F9EC454.3060605@alum.mit.edu> <05DD269BD82AA549BC4B2619BBAC466A0109F228@XMB-AMS-206.cisco.com> <4FA15144.9030307@alum.mit.edu> <05DD269BD82AA549BC4B2619BBAC466A0109F407@XMB-AMS-206.cisco.com> <4FA2AB5D.7050205@alum.mit.edu> <44C6B6B2D0CF424AA90B6055548D7A6102FD51ED1C@CRPMBOXPRD01.polycom.com> In-Reply-To: <44C6B6B2D0CF424AA90B6055548D7A6102FD51ED1C@CRPMBOXPRD01.polycom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] ways of managing presentations in telepresence sessions X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 04 May 2012 13:26:58 -0000 On 5/4/12 9:06 AM, Duckworth, Mark wrote: > Paul asked: > " when selecting which capture scene entries and captures to receive, the recipient > will be able to identify audio/video pairs so that they can be selected as a > pair?" > > Yes, this is one of the functions of capture scenes. If the provider is advertising an audio/video pair, then the provider puts the video in a capture scene entry and the audio in another capture scene entry and puts both these capture scene entries into the same capture scene. So the consumer knows the audio and video are part of the same capture scene, so the consumer can select them both and render them together. > > Mark Perhaps that is part of the answer, but maybe not all of it. Is it the case that all captures from the same scene should be synchronized? (That seems plausible to me.) I guess that suggests that captures from *different* scenes need not be synchronized. Suppose there are two presentation video captures and two presentation audio captures in the same scene. And suppose a receiver can't handle two. If it selects one of the videos, how does it select the audio that matches it? I guess at one level it could attempt to correlate them by spatial position. Or, perhaps whatever attribute it uses to select one of the videos can be used to select one of the audios. (I think that falls back to having additional attribute(s) to describe the source and/or content of a capture. We've already discussed that.) Thanks, Paul From magnus.westerlund@ericsson.com Fri May 4 06:28:57 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F49121F86F6 for ; Fri, 4 May 2012 06:28:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.7 X-Spam-Level: X-Spam-Status: No, score=-105.7 tagged_above=-999 required=5 tests=[AWL=-0.321, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, SARE_MLH_Stock1=0.87, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eVfc1i-Cda8f for ; Fri, 4 May 2012 06:28:57 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id BD30D21F86EF for ; Fri, 4 May 2012 06:28:56 -0700 (PDT) X-AuditID: c1b4fb25-b7b18ae000000dce-3d-4fa3d9977c10 Authentication-Results: mailgw2.ericsson.se x-tls.subject="/CN=esessmw0256"; auth=fail (cipher=AES128-SHA) Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client CN "esessmw0256", Issuer "esessmw0256" (not verified)) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 5F.C1.03534.799D3AF4; Fri, 4 May 2012 15:28:55 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.213.0; Fri, 4 May 2012 15:28:55 +0200 Message-ID: <4FA3D996.3020500@ericsson.com> Date: Fri, 4 May 2012 15:28:54 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: clue@ietf.org References: <4FA3D650.4060509@ericsson.com> In-Reply-To: <4FA3D650.4060509@ericsson.com> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: Re: [clue] Host and Local Information for Stockholm Interim X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 04 May 2012 13:28:57 -0000 For people that have problems accessing dropbox please try this location instead. http://www.denstore.se/IETF/Practical%20Information%20for%20CLUE%20and%20WebRTC.htm Cheers Magnus On 2012-05-04 15:14, Magnus Westerlund wrote: > WG, > > We at Ericsson hosting the meeting have now secured meeting rooms for > the Interim. Therefore I can now announce that we will be holding the > meeting in Kista. > > We also provide some more information about Kista, Hotels and travel in > Stockholm. I would recommend that people secure a hotel booking as soon > as possible as there is quite some pressure on hotel rooms during the > period of the Interim. > > Please see for details: > http://dl.dropbox.com/u/11888030/Practical%20Information%20for%20CLUE%20and%20WebRTC.htm > > Questions to the host about the location etc can be sent to me. > > Best Regards > > 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 > ---------------------------------------------------------------------- > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > -- 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 johaniel@cisco.com Fri May 4 07:29:59 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2628C21F876D for ; Fri, 4 May 2012 07:29:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dFYDsejVlIRk for ; Fri, 4 May 2012 07:29:57 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id E104621F876A for ; Fri, 4 May 2012 07:29:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=johaniel@cisco.com; l=39957; q=dns/txt; s=iport; t=1336141794; x=1337351394; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=2GIAWtkh8Z52Bx0eXloA4v9Wjj031u8hTL4xEGUoyhQ=; b=buHHiYHd97WEm/uABP4a6uqY2ixmIkOXjK4uqqh8C1NgYd1NOvG4+K57 g/igka4vsxOdhclOouzGLuvfPqDiMMkfoIBQ3WDCHTNTOFQGEOkZMG6k6 lmrAYO9LSLk10peEEWZZqreH0H+a/gZ0tVu/vsysSjwzG4qN95iwutVxl o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAEfno0+Q/khM/2dsb2JhbAA7CoJGsB2BB4IJAQEBAwEBAQEPAQcCEQM4BgsFBwQCAQgRBAEBAQoGBQsBBgEGASYfCQgBAQQBEggTB4VvgXcFC5ploBgEiwGCW4JOYwSkV4FpgmqBUggN X-IronPort-AV: E=Sophos;i="4.75,530,1330905600"; d="scan'208,217";a="137065797" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 04 May 2012 14:29:49 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q44ETnAF023101; Fri, 4 May 2012 14:29:49 GMT Received: from xmb-ams-206.cisco.com ([144.254.75.17]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 4 May 2012 16:29:49 +0200 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_01CD2A02.5C6676BA" Date: Fri, 4 May 2012 16:29:48 +0200 Message-ID: <05DD269BD82AA549BC4B2619BBAC466A0109F5B6@XMB-AMS-206.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] ways of managing presentations in telepresence sessions Thread-Index: Ac0pz6Q2dYFV+PiGRxG44OXl3dEHBwAMjQ7A References: <4F997E6B.7070501@alum.mit.edu><4F9B0D81.4040608@alum.mit.edu><4F9EC454.3060605@alum.mit.edu><05DD269BD82AA549BC4B2619BBAC466A0109F228@XMB-AMS-206.cisco.com><4FA15144.9030307@alum.mit.edu><05DD269BD82AA549BC4B2619BBAC466A0109F407@XMB-AMS-206.cisco.com><4fa295be.0852b40a.771f.1804@mx.google.com> From: "Johan Ludvig Nielsen (johaniel)" To: "Stephen Botzko" , "Brian Rosen" X-OriginalArrivalTime: 04 May 2012 14:29:49.0673 (UTC) FILETIME=[5CAC9D90:01CD2A02] Cc: CLUE Subject: Re: [clue] ways of managing presentations in telepresence sessions X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 04 May 2012 14:29:59 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD2A02.5C6676BA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I fully agree with Stephen. I have pointed out a challenge in having several endpoints in the same room connected to the same conference (or another for that matter). Implying that I think it should be avoided, not that we should solve it. =20 Regards Johan =20 =20 From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Stephen Botzko Sent: 4. mai 2012 10:27 To: Brian Rosen Cc: CLUE; Johan Ludvig Nielsen (johaniel) Subject: Re: [clue] ways of managing presentations in telepresence sessions =20 Of course it is a real problem, it happens every day. The exact same issue occurs with mixes of speaker phones, mobile phones, PCs, and traditional video conferencing all the time. The problem is not unique to multi-stream endpoints, and is not made worse by CLUE. =20 The only solutions that work are to (a) route the presentation audio output into an telepresence room audio input, instead of using built-in speakers in the presentation system and (b) disconnect the presentation audio output and (c) mute the presentation audio output. These solutions are physical, and do not involve the normal signaling layers we develop in the IETF. Detection of the echo/feedback path can in principle be done in the media plane, though it does add complexity to each endpoint. Detecting it through signaling is problematic, since the various devices involved often use different protocols, and therefore have no common knowledge of what audio conference they are in. There are also scenarios where the echo/feedback path occurs with independent audio bridges (or no bridges at all). And there is no ability to identify that the devices are in the same location and that they both have open microphones or speakers. Eliminating the echo/feedback automatically is also challenging, since you need to identify the best devices to mute, and create a mechanism which can block the problematic signaling path(s). Such a mechanism can also be exploited to launch a denial of service attack. In my view this is clearly not a CLUE issue, and I don't see much hope for a workable signaling solution no matter where it is done.=20 Stephen Botzko On Thu, May 3, 2012 at 11:17 PM, Brian Rosen wrote: Because it's not a common problem, and there is no right way to do it. =20 Having the telepresence audio/video on one system and the presentation system on another is probably more common that having them on the same system. =20 Brian =20 On May 3, 2012, at 4:40 PM, Stephen Botzko wrote: I have two separate speakerphones from two vendors in one room calling into the same audio conference. They interact in a way that utterly fails to deliver usable audio to phones in other locations. We don't have mechanisms in SIP to represent this or prevent the bad behaviour. =20 This is a problem for the IETF because???? Stephen Botzko On Thu, May 3, 2012 at 6:18 PM, Brian Rosen wrote: I go back to what I see is the fundamental issue: You have two separate systems from two vendors in one room. They interact in a way that is important to other rooms. We don't have mechanisms to represent this. Brian On May 3, 2012, at 10:25 AM, Roni Even wrote: > Hi, > See inline > Roni > >> -----Original Message----- >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of >> Johan Ludvig Nielsen (johaniel) >> Sent: Thursday, May 03, 2012 4:02 PM >> To: Paul Kyzivat >> Cc: CLUE >> Subject: Re: [clue] ways of managing presentations in telepresence >> sessions >> >> Sorry for being unclear. I am commenting on the implied option of >> rendering presentation on a separate system, either on one or several >> computers or a dedicated endpoint separate from the telepresence system >> in the room. >> >> My main point is that all audio belonging to a conference and being >> played back in a room must be controlled by or at least known to the >> audio processing unit sending audio _from_ that room. This is to avoid >> echo or multi-path problems. >> >> One example of such a problem is if a presentation in the form of a >> movie with a soundtrack is played back on a computer separate from the >> telepresence system in the room. The microphone system in the room will >> pick up the sound from the computer's loudspeakers and happily transmit >> that as voice into the conference. The presentation audio is then >> delivered to other sites through two different paths with different >> delays, one of them with poor quality. > > This is not a problem of the current protocols, you can send two audio > streams in SIP and assign a different content attribute to each of them. The > issue of the local echo of the movie sound to the people audio is a local > system issue and not a standard issue. As for handling two audio streams > this will require a definition like H.239 for this case in order to achieve > interoperability. >> >> The other (and totally separate) point I am making is that with CLUE we >> will have the ability to send presentation audio as a separate stream, >> and that we are happy about that. Today locally input presentation >> audio is most often mixed with the mic signal and sent in the main >> audio stream (which can be stereo). There is no H.239 equivalent for >> audio. > > Sending two separate audio is not a CLUE feature, it can be done by offering > two audio RTP sessions for example. > >> >> Regards >> Johan >> >> >> >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >> Sent: 2. mai 2012 17:23 >> To: Johan Ludvig Nielsen (johaniel) >> Cc: Stephen Botzko; CLUE >> Subject: Re: [clue] ways of managing presentations in telepresence >> sessions >> >> On 5/2/12 8:06 AM, Johan Ludvig Nielsen (johaniel) wrote: >>> I just want to remind you all that presentation often means video >>> _and_ audio, for instance a movie clip with a stereo soundtrack. >>> Sometimes presentation means only audio. Hook up your favourite >> device >> >>> and share a music clip or an interesting recording. >>> >>> Any presentation audio played back locally must be controlled by, or >>> at least be exactly (in sample sync) known to, the local telepresence >>> system controller. A totally separate endpoint for presentation will >>> therefore cause some practical problems. >>> >>> By the way, one very useful effect of CLUE is the ability for >>> receiving endpoints to distinguish between audio from live talking >>> sources and presentations/recordings. >> >> I'm not sure I understand the point you are making. >> Certainly it is true that a presentation may consist of audio and >> video. >> But its not just presentations that can contain paired audio and video. >> When we have many audio and video captures, there could be several >> pairs. >> >> RFC3388 provides a way (a=3Dmid:ls) to indicate when lip sync is >> required. >> Do we need more than that? Should advertisements indicate desirable >> audio/video pairings so that selection can take that into account? >> >> Thanks, >> Paul >> >>> Johan >>> >>> *From:*clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On >> Behalf >> >>> Of *Stephen Botzko >>> *Sent:* 1. mai 2012 09:11 >>> *To:* Paul Kyzivat >>> *Cc:* CLUE >>> *Subject:* Re: [clue] ways of managing presentations in telepresence >>> sessions >>> >>> On Mon, Apr 30, 2012 at 12:56 PM, Paul Kyzivat >> > wrote: >>> >>> On 4/28/12 1:18 PM, Stephen Botzko wrote: >>> >>> [sb] As I mentioned above, the existing solutions usually include a >>> screen-scrape application, so you don't have to use a video cable. >>> This is essentially the same as using Webex for presenting (but not >>> remote control). >>> >>> How are these solutions connected? Does the captured application data >>> go to the local room controller, or to an MCU in the middle of the TP >>> session? Or something else? >>> >>> [sb] They are normally connected to the local room telepresence >> system. >>> Again, the people in the local room also need to see the >> presentation, >> >>> so this is the most direct and also is the most bandwidth efficient >>> approach. Another aspect is that the rooms can and are used purely >>> locally (with no remote systems at all), and presentations also need >>> to work in that situation. BTW I think adding requirements for >> support >> >>> of multiple endpoints in the same room is an unwise path - this is >> not >> >>> SPLICES, and we have enough to do already. I agree with folks who are >>> saying it is out of scope[/sb] >>> >>> Also, even though Webex allows remote control, in my >>> experience that feature is not used as much as simple >>> presenting. I am >>> not saying it has no value, just that the most common case I >> see >>> is a >>> simple presentation. >>> >>> That is my experience as well. I wasn't thinking about the >>> multi-user-control aspect. >>> >>> Supporting the video cable still has value, especially if you >>> have guest >>> presenter who does not have access to your local network. >> Most >>> of those >>> presenters are expecting to use a projector, so they have the >> cables >>> with them. >>> >>> Surely. In this case, I presume the cable connects to the local >> room >>> controller. If there are multiple cable connectors (e.g. one at >> each >>> seat) do they show up as multiple presentation streams? Or is >> there >>> some sort of switch and floor control? If so, how does one manage >>> the floor control? >>> >>> [sb] Today there is one presenter at a time. With multiple >> cables, >>> there is usually a button at each spot, and if you press it you >>> become the presenter (most recent request wins is the policy). >>> Normal social courtesies handle conflict, so there is no real >> need >>> for formal floor control. This happens even in ordinary webex >>> conferences - if someone grabs the ball when they shouldn't have >> it, >>> people say something and it gets resolved. Similarly, if someone >>> needs the ball. More precisely, the presenting video system holds >>> the token for the room. With H.239, the MCU (if there is one) >> grants >>> it, using whatever policy it wants, and can revoke it at any >> time. >>> In point-to-point calls, the far end SHALL grant it upon request, >> so >>> in that case the turn-taking policy is mandated in the standard. >>> Multiple presenters in the same room is up to the local room >> policy >>> - there is no standard, and in my opinion none is needed. The >> token >>> remains owned by the local video system, it is allowed to present >>> whatever local source it wishes. [/sb] >>> >>> My answer on application sharing falling "out of favor" >> related >>> specifically to vendor support for standards-based >> application >>> sharing >>> (T.120 in particular) - which I thought was responsive to >> your >>> original >>> question. Perhaps I misunderstood it. Anyway there were >> several >>> reasons [and perhaps various viewpoints] on why T.120 was >> dropped, >>> though I think it is probably not a useful discussion for >> this >>> list. I >>> know of no other standards-based protocol for application >> sharing. >>> >>> I wasn't assuming there was, other than a pure video (and maybe >>> audio) stream interface. There are other fora for that sort of >>> thing, but its my impression that this is largely a world of >>> proprietary and defacto standards. >>> >>> BTW, it is relatively common for web screen sharing to >> co-exist >>> with the >>> videoconferencing presentation methods. For instance, you can >> have a >>> stand-alone webex conference, with someone sharing their >> laptop >>> screen >>> for the video participants.[/sb] >>> >>> I have done this. But it was cumbersome. IIRC, getting the >> sharing >>> to be visible in the room I was in required using a video cable >> in >>> addition to using webex sharing. >>> >>> [sb]With our equipment you could use the cable if you wished, but it >>> would not be required. Though generally speaking, people are used to >>> using projectors for presenting. Video systems are providing >> identical >> >>> interfaces, so they work the way people expect. For instance, in IETF >>> interim meetings the Webex screen is always presented locally, >>> frequently using a cable. The chairs may find that cumbersome, but >>> they certainly come into the meeting expecting to do it anyway.[\sb] >>> >>> Of course that is still somewhat cumbersome, but presumably >> it >> will >>> be improved over time. Its the UI for driving it that is >> cumbersome, >>> not the output. >>> >>> A key difference is that if the computer output is via video >> cable >>> into the local room controller, then that is probably >> responsible >>> for displaying it locally on a display in the room as well as >>> sending it to the remote end. If the users connect their >> computers >>> directly to the MCU, then the capture will come to the room >> just >>> like anything else from the MCU. >>> >>> [sb]The standard model for videoconferencing presentations is >> a >>> token-controlled transmission. If you don't have the token, >> you are >>> receiving. The local equipment is always responsible for >> display. >>> Looping the presentation back through the MCU back to the >>> originating >>> site wastes bandwidth. >>> >>> I don't know if web conferencing solutions do this >> differently >>> or not. >>> I've always assumed that when I grab the webex "ball" I stop >>> receiving >>> desktop images. Certainly there is no reason for the server >> to >> send >>> them back to me.[/sb] >>> >>> >>> Thanks, >>> Paul >>> >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue =20 =20 =20 ------_=_NextPart_001_01CD2A02.5C6676BA Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I fully agree with Stephen. I have pointed out a challenge in having = several endpoints in the same room connected to the same conference (or = another for that matter). Implying that I think it should be avoided, = not that we should solve it.

 

Regards

Johan

 

 

From:= = clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of = Stephen Botzko
Sent: 4. mai 2012 10:27
To: Brian = Rosen
Cc: CLUE; Johan Ludvig Nielsen = (johaniel)
Subject: Re: [clue] ways of managing presentations = in telepresence sessions

 

Of course it is a real problem, it = happens every day. The exact same issue occurs with mixes of speaker = phones, mobile phones, PCs,  and traditional video conferencing all = the time.  The problem is not unique to multi-stream endpoints, and = is not made worse by CLUE. 

The only solutions that work = are to (a) route the presentation audio output into an telepresence room = audio input, instead of using built-in speakers in the presentation = system and (b) disconnect the presentation audio output and (c) mute the = presentation audio output.  These solutions are physical, and do = not involve the normal signaling layers we develop in the = IETF.

Detection of the echo/feedback path can in principle be = done in the media plane, though it does add complexity to each = endpoint.

Detecting it through signaling is problematic, since = the various devices involved often use different protocols, and = therefore have no common knowledge of what audio conference they are = in.  There are also scenarios where the echo/feedback path occurs = with independent audio bridges (or no bridges at all).  And = there is no ability to identify that the devices are in the same = location and that they both have open microphones or = speakers.

Eliminating the echo/feedback automatically is also = challenging, since you need to identify the best devices to mute, and = create a mechanism which can block the problematic signaling = path(s).  Such a mechanism can also be exploited to launch a denial = of service attack.

In my view this is clearly not a CLUE issue, = and I don't see much hope for a workable signaling solution no matter = where it is done.

Stephen Botzko

On Thu, May 3, 2012 at 11:17 PM, Brian Rosen <br@brianrosen.net> wrote:

Because it's not a common problem, and there is no = right way to do it.

 

Having the telepresence audio/video on one system and = the presentation system on another is probably more common that having = them on the same system.

 

Brian

<= p class=3DMsoNormal> 

On May 3, 2012, at 4:40 PM, Stephen Botzko = wrote:



I have two separate speakerphones from = two vendors in one room calling into the same audio conference.  = They interact in a way that utterly fails to deliver usable audio to = phones in other locations.  We don't have mechanisms in SIP to = represent this or prevent the bad behaviour. 

This is a = problem for the IETF because????

Stephen = Botzko

On Thu, May 3, 2012 at = 6:18 PM, Brian Rosen <br@brianrosen.net> wrote:

I go back to what I see is the fundamental = issue:

You have two separate systems from two vendors in one = room.  They interact in a way that is important to other rooms. =  We don't have mechanisms to represent this.

Brian


On May 3, 2012, at 10:25 AM, Roni Even = wrote:

> Hi,
> See inline
> = Roni
>
>> -----Original Message-----
>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of
>> = Johan Ludvig Nielsen (johaniel)
>> Sent: Thursday, May 03, 2012 = 4:02 PM
>> To: Paul Kyzivat
>> Cc: CLUE
>> = Subject: Re: [clue] ways of managing presentations in = telepresence
>> sessions
>>
>> Sorry for = being unclear. I am commenting on the implied option of
>> = rendering presentation on a separate system, either on one or = several
>> computers or a dedicated endpoint separate from the = telepresence system
>> in the room.
>>
>> My = main point is that all audio belonging to a conference and = being
>> played back in a room must be controlled by or at = least known to the
>> audio processing unit sending audio = _from_ that room. This is to avoid
>> echo or multi-path = problems.
>>
>> One example of such a problem is if a = presentation in the form of a
>> movie with a soundtrack is = played back on a computer separate from the
>> telepresence = system in the room. The microphone system in the room will
>> = pick up the sound from the computer's loudspeakers and happily = transmit
>> that as voice into the conference. The presentation = audio is then
>> delivered to other sites through two different = paths with different
>> delays, one of them with poor = quality.
>
> This is not a problem of the current protocols, = you can send two audio
> streams in SIP and assign a different = content attribute to each of them. The
> issue of the local echo = of the movie sound to the people audio is a local
> system issue = and not a standard issue. As for handling two audio streams
> this = will require a definition like H.239 for this case in order to = achieve
> interoperability.
>>
>> The other (and = totally separate) point I am making is that with CLUE we
>> = will have the ability to send presentation audio as a separate = stream,
>> and that we are happy about that. Today locally = input presentation
>> audio is most often mixed with the mic = signal and sent in the main
>> audio stream (which can be = stereo). There is no H.239 equivalent for
>> = audio.
>
> Sending two separate audio is not a CLUE feature, = it can be done by offering
> two audio RTP sessions for = example.
>
>>
>> Regards
>> = Johan
>>
>>
>>
>> -----Original = Message-----
>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]
>> Sent: 2. mai = 2012 17:23
>> To: Johan Ludvig Nielsen (johaniel)
>> = Cc: Stephen Botzko; CLUE
>> Subject: Re: [clue] ways of = managing presentations in telepresence
>> = sessions
>>
>> On 5/2/12 8:06 AM, Johan Ludvig Nielsen = (johaniel) wrote:
>>> I just want to remind you all that = presentation often means video
>>> _and_ audio, for instance = a movie clip with a stereo soundtrack.
>>> Sometimes = presentation means only audio. Hook up your favourite
>> = device
>>
>>> and share a music clip or an = interesting recording.
>>>
>>> Any presentation = audio played back locally must be controlled by, or
>>> at = least be exactly (in sample sync) known to, the local = telepresence
>>> system controller. A totally separate = endpoint for presentation will
>>> therefore cause some = practical problems.
>>>
>>> By the way, one very = useful effect of CLUE is the ability for
>>> receiving = endpoints to distinguish between audio from live talking
>>> = sources and presentations/recordings.
>>
>> I'm not = sure I understand the point you are making.
>> Certainly it is = true that a presentation may consist of audio and
>> = video.
>> But its not just presentations that can contain = paired audio and video.
>> When we have many audio and video = captures, there could be several
>> = pairs.
>>
>> RFC3388 provides a way (a=3Dmid:ls) to = indicate when lip sync is
>> required.
>> Do we need = more than that? Should advertisements indicate desirable
>> = audio/video pairings so that selection can take that into = account?
>>
>>      Thanks,
>> =      Paul
>>
>>> = Johan
>>>
>>> *From:*clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On
>> = Behalf
>>
>>> Of *Stephen Botzko
>>> = *Sent:* 1. mai 2012 09:11
>>> *To:* Paul = Kyzivat
>>> *Cc:* CLUE
>>> *Subject:* Re: [clue] = ways of managing presentations in telepresence
>>> = sessions
>>>
>>> On Mon, Apr 30, 2012 at 12:56 = PM, Paul Kyzivat <pkyzivat@alum.mit.edu
>>> = <mailto:pkyzivat@alum.mit.edu>> = wrote:
>>>
>>> On 4/28/12 1:18 PM, Stephen = Botzko wrote:
>>>
>>> [sb] As I mentioned above, = the existing solutions usually include a
>>> screen-scrape = application, so you don't have to use a video cable.
>>> = This is essentially the same as using Webex for presenting (but = not
>>> remote control).
>>>
>>> How = are these solutions connected? Does the captured application = data
>>> go to the local room controller, or to an MCU in = the middle of the TP
>>> session? Or something = else?
>>>
>>> [sb] They are normally connected = to the local room telepresence
>> system.
>>> = Again, the people in the local room also need to see the
>> = presentation,
>>
>>> so this is the most direct and = also is the most bandwidth efficient
>>> approach. Another = aspect is that the rooms can and are used purely
>>> locally = (with no remote systems at all), and presentations also = need
>>> to work in that situation. BTW I think adding = requirements for
>> support
>>
>>> of = multiple endpoints in the same room is an unwise path - this = is
>> not
>>
>>> SPLICES, and we have = enough to do already. I agree with folks who are
>>> saying = it is out of scope[/sb]
>>>
>>>     =    Also, even though Webex allows remote control, in = my
>>>        experience that feature is = not used as much as simple
>>>       =  presenting. I am
>>>        not = saying it has no value, just that the most common case I
>> = see
>>>        is a
>>> =        simple = presentation.
>>>
>>>    That is my = experience as well. I wasn't thinking about the
>>>   =  multi-user-control aspect.
>>>
>>>   =      Supporting the video cable still has value, = especially if you
>>>        have = guest
>>>        presenter who does not = have access to your local network.
>> Most
>>> =        of those
>>>       =  presenters are expecting to use a projector, so they have = the
>> cables
>>>        with = them.
>>>
>>>    Surely. In this case, = I presume the cable connects to the local
>> = room
>>>    controller. If there are multiple = cable connectors (e.g. one at
>> each
>>>   =  seat) do they show up as multiple presentation streams? Or = is
>> there
>>>    some sort of switch = and floor control? If so, how does one manage
>>>   =  the floor control?
>>>
>>>   =  [sb] Today there is one presenter at a time. With = multiple
>> cables,
>>>    there is = usually a button at each spot, and if you press it you
>>> =    become the presenter (most recent request wins is the = policy).
>>>    Normal social courtesies handle = conflict, so there is no real
>> need
>>>   =  for formal floor control. This happens even in ordinary = webex
>>>    conferences - if someone grabs the = ball when they shouldn't have
>> it,
>>>   =  people say something and it gets resolved. Similarly, if = someone
>>>    needs the ball. More precisely, the = presenting video system holds
>>>    the token for = the room. With H.239, the MCU (if there is one)
>> = grants
>>>    it, using whatever policy it wants, = and can revoke it at any
>> time.
>>>   =  In point-to-point calls, the far end SHALL grant it upon = request,
>> so
>>>    in that case the = turn-taking policy is mandated in the standard.
>>>   =  Multiple presenters in the same room is up to the local = room
>> policy
>>>    - there is no = standard, and in my opinion none is needed. The
>> = token
>>>    remains owned by the local video = system, it is allowed to present
>>>    whatever = local source it wishes. [/sb]
>>>
>>>   =      My answer on application sharing falling "out = of favor"
>> related
>>>       =  specifically to vendor support for standards-based
>> = application
>>>       =  sharing
>>>        (T.120 in = particular) - which I thought was responsive to
>> = your
>>>        original
>>> =        question. Perhaps I misunderstood it. Anyway = there were
>> several
>>>       =  reasons [and perhaps various viewpoints] on why T.120 = was
>> dropped,
>>>       =  though I think it is probably not a useful discussion = for
>> this
>>>        list. = I
>>>        know of no other = standards-based protocol for application
>> = sharing.
>>>
>>>    I wasn't assuming = there was, other than a pure video (and maybe
>>>   =  audio) stream interface. There are other fora for that sort = of
>>>    thing, but its my impression that this = is largely a world of
>>>    proprietary and = defacto standards.
>>>
>>>       =  BTW, it is relatively common for web screen sharing to
>> = co-exist
>>>        with = the
>>>        videoconferencing = presentation methods. For instance, you can
>> have = a
>>>        stand-alone webex = conference, with someone sharing their
>> = laptop
>>>        screen
>>> =        for the video = participants.[/sb]
>>>
>>>    I have = done this. But it was cumbersome. IIRC, getting the
>> = sharing
>>>    to be visible in the room I was in = required using a video cable
>> in
>>>   =  addition to using webex sharing.
>>>
>>> = [sb]With our equipment you could use the cable if you wished, but = it
>>> would not be required. Though generally speaking, = people are used to
>>> using projectors for presenting. = Video systems are providing
>> = identical
>>
>>> interfaces, so they work the way = people expect. For instance, in IETF
>>> interim meetings = the Webex screen is always presented locally,
>>> frequently = using a cable. The chairs may find that cumbersome, but
>>> = they certainly come into the meeting expecting to do it = anyway.[\sb]
>>>
>>>       =  Of course that is still somewhat cumbersome, but = presumably
>> it
>> will
>>>     =    be improved over time. Its the UI for driving it that = is
>> cumbersome,
>>>       =  not the output.
>>>
>>>     =    A key difference is that if the computer output is via = video
>> cable
>>>        into = the local room controller, then that is probably
>> = responsible
>>>        for displaying it = locally on a display in the room as well as
>>>   =      sending it to the remote end. If the users connect = their
>> computers
>>>       =  directly to the MCU, then the capture will come to the = room
>> just
>>>        like = anything else from the MCU.
>>>
>>>   =      [sb]The standard model for videoconferencing = presentations is
>> a
>>>       =  token-controlled transmission. If you don't have the = token,
>> you are
>>>       =  receiving. The local equipment is always responsible = for
>> display.
>>>       =  Looping the presentation back through the MCU back to = the
>>>       =  originating
>>>        site wastes = bandwidth.
>>>
>>>        I = don't know if web conferencing solutions do this
>> = differently
>>>        or = not.
>>>        I've always assumed that = when I grab the webex "ball" I stop
>>>   =      receiving
>>>       =  desktop images. Certainly there is no reason for the = server
>> to
>> send
>>>     =    them back to = me.[/sb]
>>>
>>>
>>>   =  Thanks,
>>>   =  Paul
>>>
>>
>> = _______________________________________________
>> clue mailing = list
>> clue@ietf.org
>> https://www.ietf.org/mailman/listinfo/clue
><= br>> _______________________________________________
> 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_01CD2A02.5C6676BA-- From br@brianrosen.net Fri May 4 08:02:24 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCE6D21F86A2 for ; Fri, 4 May 2012 08:02:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.565 X-Spam-Level: X-Spam-Status: No, score=-102.565 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dGReRTk1xXAd for ; Fri, 4 May 2012 08:02:16 -0700 (PDT) Received: from barmail6.idig.net (barmail6.idig.net [64.34.111.236]) by ietfa.amsl.com (Postfix) with ESMTP id 1EA4021F85B8 for ; Fri, 4 May 2012 08:02:16 -0700 (PDT) X-ASG-Debug-ID: 1336143733-05376a26e82c800001-dOUo1C Received: from wwh1.winweblinux.com (wwh1.winweblinux.com [76.74.186.184]) by barmail6.idig.net with ESMTP id ZHHXmyFazJvsy7Aj; Fri, 04 May 2012 08:02:13 -0700 (PDT) X-Barracuda-Envelope-From: br@brianrosen.net X-Barracuda-Apparent-Source-IP: 76.74.186.184 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=[156.154.4.14]) by wwh1.winweblinux.com with esmtpa (Exim 4.69) (envelope-from ) id 1SQK1M-001e1b-SE; Fri, 04 May 2012 08:02:13 -0700 Mime-Version: 1.0 (Apple Message framework v1257) X-ASG-Orig-Subj: Re: [clue] ways of managing presentations in telepresence sessions Content-Type: multipart/alternative; boundary="Apple-Mail=_A0853D9D-013E-4D89-A966-982E6459FB8C" From: Brian Rosen In-Reply-To: Date: Fri, 4 May 2012 11:02:10 -0400 Message-Id: References: <4F997E6B.7070501@alum.mit.edu> <4F9B0D81.4040608@alum.mit.edu> <4F9EC454.3060605@alum.mit.edu> <05DD269BD82AA549BC4B2619BBAC466A0109F228@XMB-AMS-206.cisco.com> <4FA15144.9030307@alum.mit.edu> <05DD269BD82AA549BC4B2619BBAC466A0109F407@XMB-AMS-206.cisco.com> <4fa295be.0852b40a.771f.1804@mx.google.com> To: Stephen Botzko X-Mailer: Apple Mail (2.1257) X-Barracuda-Connect: wwh1.winweblinux.com[76.74.186.184] X-Barracuda-Start-Time: 1336143733 X-Barracuda-URL: http://64.34.111.236:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at idig.net X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.5 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.95976 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message Cc: CLUE , "Johan Ludvig Nielsen \(johaniel\)" Subject: Re: [clue] ways of managing presentations in telepresence sessions X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 04 May 2012 15:02:24 -0000 --Apple-Mail=_A0853D9D-013E-4D89-A966-982E6459FB8C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Sorry, I wasn't clear. I'm not proposing to solve the audio problem of prerecorded audio = interacting with room audio. I'm observing that in most cases, today, there is a presentation system = that is independent of the audio/video system. Endpoints for both are = in the same room. They interact (floor control for example). We don't = have any way to describe or handle this in CLUE. It's not the same problem as multiple audio or video systems in the same = room either. Brian On May 4, 2012, at 4:26 AM, Stephen Botzko wrote: > Of course it is a real problem, it happens every day. The exact same = issue occurs with mixes of speaker phones, mobile phones, PCs, and = traditional video conferencing all the time. The problem is not unique = to multi-stream endpoints, and is not made worse by CLUE. =20 >=20 > The only solutions that work are to (a) route the presentation audio = output into an telepresence room audio input, instead of using built-in = speakers in the presentation system and (b) disconnect the presentation = audio output and (c) mute the presentation audio output. These = solutions are physical, and do not involve the normal signaling layers = we develop in the IETF. >=20 > Detection of the echo/feedback path can in principle be done in the = media plane, though it does add complexity to each endpoint. >=20 > Detecting it through signaling is problematic, since the various = devices involved often use different protocols, and therefore have no = common knowledge of what audio conference they are in. There are also = scenarios where the echo/feedback path occurs with independent audio = bridges (or no bridges at all). And there is no ability to identify = that the devices are in the same location and that they both have open = microphones or speakers. >=20 > Eliminating the echo/feedback automatically is also challenging, since = you need to identify the best devices to mute, and create a mechanism = which can block the problematic signaling path(s). Such a mechanism can = also be exploited to launch a denial of service attack. >=20 > In my view this is clearly not a CLUE issue, and I don't see much hope = for a workable signaling solution no matter where it is done.=20 >=20 > Stephen Botzko >=20 > On Thu, May 3, 2012 at 11:17 PM, Brian Rosen = wrote: > Because it's not a common problem, and there is no right way to do it. >=20 > Having the telepresence audio/video on one system and the presentation = system on another is probably more common that having them on the same = system. >=20 > Brian >=20 > On May 3, 2012, at 4:40 PM, Stephen Botzko wrote: >=20 >> I have two separate speakerphones from two vendors in one room = calling into the same audio conference. They interact in a way that = utterly fails to deliver usable audio to phones in other locations. We = don't have mechanisms in SIP to represent this or prevent the bad = behaviour. =20 >>=20 >> This is a problem for the IETF because???? >>=20 >> Stephen Botzko >>=20 >> On Thu, May 3, 2012 at 6:18 PM, Brian Rosen = wrote: >> I go back to what I see is the fundamental issue: >>=20 >> You have two separate systems from two vendors in one room. They = interact in a way that is important to other rooms. We don't have = mechanisms to represent this. >>=20 >> Brian >>=20 >> On May 3, 2012, at 10:25 AM, Roni Even wrote: >>=20 >> > Hi, >> > See inline >> > Roni >> > >> >> -----Original Message----- >> >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On = Behalf Of >> >> Johan Ludvig Nielsen (johaniel) >> >> Sent: Thursday, May 03, 2012 4:02 PM >> >> To: Paul Kyzivat >> >> Cc: CLUE >> >> Subject: Re: [clue] ways of managing presentations in telepresence >> >> sessions >> >> >> >> Sorry for being unclear. I am commenting on the implied option of >> >> rendering presentation on a separate system, either on one or = several >> >> computers or a dedicated endpoint separate from the telepresence = system >> >> in the room. >> >> >> >> My main point is that all audio belonging to a conference and = being >> >> played back in a room must be controlled by or at least known to = the >> >> audio processing unit sending audio _from_ that room. This is to = avoid >> >> echo or multi-path problems. >> >> >> >> One example of such a problem is if a presentation in the form of = a >> >> movie with a soundtrack is played back on a computer separate from = the >> >> telepresence system in the room. The microphone system in the room = will >> >> pick up the sound from the computer's loudspeakers and happily = transmit >> >> that as voice into the conference. The presentation audio is then >> >> delivered to other sites through two different paths with = different >> >> delays, one of them with poor quality. >> > >> > This is not a problem of the current protocols, you can send two = audio >> > streams in SIP and assign a different content attribute to each of = them. The >> > issue of the local echo of the movie sound to the people audio is a = local >> > system issue and not a standard issue. As for handling two audio = streams >> > this will require a definition like H.239 for this case in order to = achieve >> > interoperability. >> >> >> >> The other (and totally separate) point I am making is that with = CLUE we >> >> will have the ability to send presentation audio as a separate = stream, >> >> and that we are happy about that. Today locally input presentation >> >> audio is most often mixed with the mic signal and sent in the main >> >> audio stream (which can be stereo). There is no H.239 equivalent = for >> >> audio. >> > >> > Sending two separate audio is not a CLUE feature, it can be done by = offering >> > two audio RTP sessions for example. >> > >> >> >> >> Regards >> >> Johan >> >> >> >> >> >> >> >> -----Original Message----- >> >> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >> >> Sent: 2. mai 2012 17:23 >> >> To: Johan Ludvig Nielsen (johaniel) >> >> Cc: Stephen Botzko; CLUE >> >> Subject: Re: [clue] ways of managing presentations in telepresence >> >> sessions >> >> >> >> On 5/2/12 8:06 AM, Johan Ludvig Nielsen (johaniel) wrote: >> >>> I just want to remind you all that presentation often means video >> >>> _and_ audio, for instance a movie clip with a stereo soundtrack. >> >>> Sometimes presentation means only audio. Hook up your favourite >> >> device >> >> >> >>> and share a music clip or an interesting recording. >> >>> >> >>> Any presentation audio played back locally must be controlled by, = or >> >>> at least be exactly (in sample sync) known to, the local = telepresence >> >>> system controller. A totally separate endpoint for presentation = will >> >>> therefore cause some practical problems. >> >>> >> >>> By the way, one very useful effect of CLUE is the ability for >> >>> receiving endpoints to distinguish between audio from live = talking >> >>> sources and presentations/recordings. >> >> >> >> I'm not sure I understand the point you are making. >> >> Certainly it is true that a presentation may consist of audio and >> >> video. >> >> But its not just presentations that can contain paired audio and = video. >> >> When we have many audio and video captures, there could be several >> >> pairs. >> >> >> >> RFC3388 provides a way (a=3Dmid:ls) to indicate when lip sync is >> >> required. >> >> Do we need more than that? Should advertisements indicate = desirable >> >> audio/video pairings so that selection can take that into account? >> >> >> >> Thanks, >> >> Paul >> >> >> >>> Johan >> >>> >> >>> *From:*clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On >> >> Behalf >> >> >> >>> Of *Stephen Botzko >> >>> *Sent:* 1. mai 2012 09:11 >> >>> *To:* Paul Kyzivat >> >>> *Cc:* CLUE >> >>> *Subject:* Re: [clue] ways of managing presentations in = telepresence >> >>> sessions >> >>> >> >>> On Mon, Apr 30, 2012 at 12:56 PM, Paul Kyzivat = > >>> > wrote: >> >>> >> >>> On 4/28/12 1:18 PM, Stephen Botzko wrote: >> >>> >> >>> [sb] As I mentioned above, the existing solutions usually include = a >> >>> screen-scrape application, so you don't have to use a video = cable. >> >>> This is essentially the same as using Webex for presenting (but = not >> >>> remote control). >> >>> >> >>> How are these solutions connected? Does the captured application = data >> >>> go to the local room controller, or to an MCU in the middle of = the TP >> >>> session? Or something else? >> >>> >> >>> [sb] They are normally connected to the local room telepresence >> >> system. >> >>> Again, the people in the local room also need to see the >> >> presentation, >> >> >> >>> so this is the most direct and also is the most bandwidth = efficient >> >>> approach. Another aspect is that the rooms can and are used = purely >> >>> locally (with no remote systems at all), and presentations also = need >> >>> to work in that situation. BTW I think adding requirements for >> >> support >> >> >> >>> of multiple endpoints in the same room is an unwise path - this = is >> >> not >> >> >> >>> SPLICES, and we have enough to do already. I agree with folks who = are >> >>> saying it is out of scope[/sb] >> >>> >> >>> Also, even though Webex allows remote control, in my >> >>> experience that feature is not used as much as simple >> >>> presenting. I am >> >>> not saying it has no value, just that the most common case = I >> >> see >> >>> is a >> >>> simple presentation. >> >>> >> >>> That is my experience as well. I wasn't thinking about the >> >>> multi-user-control aspect. >> >>> >> >>> Supporting the video cable still has value, especially if = you >> >>> have guest >> >>> presenter who does not have access to your local network. >> >> Most >> >>> of those >> >>> presenters are expecting to use a projector, so they have = the >> >> cables >> >>> with them. >> >>> >> >>> Surely. In this case, I presume the cable connects to the = local >> >> room >> >>> controller. If there are multiple cable connectors (e.g. one = at >> >> each >> >>> seat) do they show up as multiple presentation streams? Or is >> >> there >> >>> some sort of switch and floor control? If so, how does one = manage >> >>> the floor control? >> >>> >> >>> [sb] Today there is one presenter at a time. With multiple >> >> cables, >> >>> there is usually a button at each spot, and if you press it = you >> >>> become the presenter (most recent request wins is the policy). >> >>> Normal social courtesies handle conflict, so there is no real >> >> need >> >>> for formal floor control. This happens even in ordinary webex >> >>> conferences - if someone grabs the ball when they shouldn't = have >> >> it, >> >>> people say something and it gets resolved. Similarly, if = someone >> >>> needs the ball. More precisely, the presenting video system = holds >> >>> the token for the room. With H.239, the MCU (if there is one) >> >> grants >> >>> it, using whatever policy it wants, and can revoke it at any >> >> time. >> >>> In point-to-point calls, the far end SHALL grant it upon = request, >> >> so >> >>> in that case the turn-taking policy is mandated in the = standard. >> >>> Multiple presenters in the same room is up to the local room >> >> policy >> >>> - there is no standard, and in my opinion none is needed. The >> >> token >> >>> remains owned by the local video system, it is allowed to = present >> >>> whatever local source it wishes. [/sb] >> >>> >> >>> My answer on application sharing falling "out of favor" >> >> related >> >>> specifically to vendor support for standards-based >> >> application >> >>> sharing >> >>> (T.120 in particular) - which I thought was responsive to >> >> your >> >>> original >> >>> question. Perhaps I misunderstood it. Anyway there were >> >> several >> >>> reasons [and perhaps various viewpoints] on why T.120 was >> >> dropped, >> >>> though I think it is probably not a useful discussion for >> >> this >> >>> list. I >> >>> know of no other standards-based protocol for application >> >> sharing. >> >>> >> >>> I wasn't assuming there was, other than a pure video (and = maybe >> >>> audio) stream interface. There are other fora for that sort of >> >>> thing, but its my impression that this is largely a world of >> >>> proprietary and defacto standards. >> >>> >> >>> BTW, it is relatively common for web screen sharing to >> >> co-exist >> >>> with the >> >>> videoconferencing presentation methods. For instance, you = can >> >> have a >> >>> stand-alone webex conference, with someone sharing their >> >> laptop >> >>> screen >> >>> for the video participants.[/sb] >> >>> >> >>> I have done this. But it was cumbersome. IIRC, getting the >> >> sharing >> >>> to be visible in the room I was in required using a video = cable >> >> in >> >>> addition to using webex sharing. >> >>> >> >>> [sb]With our equipment you could use the cable if you wished, but = it >> >>> would not be required. Though generally speaking, people are used = to >> >>> using projectors for presenting. Video systems are providing >> >> identical >> >> >> >>> interfaces, so they work the way people expect. For instance, in = IETF >> >>> interim meetings the Webex screen is always presented locally, >> >>> frequently using a cable. The chairs may find that cumbersome, = but >> >>> they certainly come into the meeting expecting to do it = anyway.[\sb] >> >>> >> >>> Of course that is still somewhat cumbersome, but = presumably >> >> it >> >> will >> >>> be improved over time. Its the UI for driving it that is >> >> cumbersome, >> >>> not the output. >> >>> >> >>> A key difference is that if the computer output is via = video >> >> cable >> >>> into the local room controller, then that is probably >> >> responsible >> >>> for displaying it locally on a display in the room as well = as >> >>> sending it to the remote end. If the users connect their >> >> computers >> >>> directly to the MCU, then the capture will come to the = room >> >> just >> >>> like anything else from the MCU. >> >>> >> >>> [sb]The standard model for videoconferencing presentations = is >> >> a >> >>> token-controlled transmission. If you don't have the = token, >> >> you are >> >>> receiving. The local equipment is always responsible for >> >> display. >> >>> Looping the presentation back through the MCU back to the >> >>> originating >> >>> site wastes bandwidth. >> >>> >> >>> I don't know if web conferencing solutions do this >> >> differently >> >>> or not. >> >>> I've always assumed that when I grab the webex "ball" I = stop >> >>> receiving >> >>> desktop images. Certainly there is no reason for the = server >> >> to >> >> send >> >>> them back to me.[/sb] >> >>> >> >>> >> >>> Thanks, >> >>> Paul >> >>> >> >> >> >> _______________________________________________ >> >> 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 >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >>=20 >=20 >=20 --Apple-Mail=_A0853D9D-013E-4D89-A966-982E6459FB8C Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=iso-8859-1
Sorry, I wasn't clear.

I'm not proposing to solve the audio problem of prerecorded audio interacting with room audio.

I'm observing that in most cases, today, there is a presentation system that is independent of the audio/video system.  Endpoints for both are in the same room.  They interact (floor control for example).  We don't have any way to describe or handle this in CLUE.

It's not the same problem as multiple audio or video systems in the same room either.

Brian

On May 4, 2012, at 4:26 AM, Stephen Botzko wrote:

Of course it is a real problem, it happens every day. The exact same issue occurs with mixes of speaker phones, mobile phones, PCs,  and traditional video conferencing all the time.  The problem is not unique to multi-stream endpoints, and is not made worse by CLUE. 

The only solutions that work are to (a) route the presentation audio output into an telepresence room audio input, instead of using built-in speakers in the presentation system and (b) disconnect the presentation audio output and (c) mute the presentation audio output.  These solutions are physical, and do not involve the normal signaling layers we develop in the IETF.

Detection of the echo/feedback path can in principle be done in the media plane, though it does add complexity to each endpoint.

Detecting it through signaling is problematic, since the various devices involved often use different protocols, and therefore have no common knowledge of what audio conference they are in.  There are also scenarios where the echo/feedback path occurs with independent audio bridges (or no bridges at all).  And there is no ability to identify that the devices are in the same location and that they both have open microphones or speakers.

Eliminating the echo/feedback automatically is also challenging, since you need to identify the best devices to mute, and create a mechanism which can block the problematic signaling path(s).  Such a mechanism can also be exploited to launch a denial of service attack.

In my view this is clearly not a CLUE issue, and I don't see much hope for a workable signaling solution no matter where it is done.

Stephen Botzko

On Thu, May 3, 2012 at 11:17 PM, Brian Rosen <br@brianrosen.net> wrote:
Because it's not a common problem, and there is no right way to do it.

Having the telepresence audio/video on one system and the presentation system on another is probably more common that having them on the same system.

Brian

On May 3, 2012, at 4:40 PM, Stephen Botzko wrote:

I have two separate speakerphones from two vendors in one room calling into the same audio conference.  They interact in a way that utterly fails to deliver usable audio to phones in other locations.  We don't have mechanisms in SIP to represent this or prevent the bad behaviour. 

This is a problem for the IETF because????

Stephen Botzko

On Thu, May 3, 2012 at 6:18 PM, Brian Rosen <br@brianrosen.net> wrote:
I go back to what I see is the fundamental issue:

You have two separate systems from two vendors in one room.  They interact in a way that is important to other rooms.  We don't have mechanisms to represent this.

Brian

On May 3, 2012, at 10:25 AM, Roni Even wrote:

> Hi,
> See inline
> Roni
>
>> -----Original Message-----
>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of
>> Johan Ludvig Nielsen (johaniel)
>> Sent: Thursday, May 03, 2012 4:02 PM
>> To: Paul Kyzivat
>> Cc: CLUE
>> Subject: Re: [clue] ways of managing presentations in telepresence
>> sessions
>>
>> Sorry for being unclear. I am commenting on the implied option of
>> rendering presentation on a separate system, either on one or several
>> computers or a dedicated endpoint separate from the telepresence system
>> in the room.
>>
>> My main point is that all audio belonging to a conference and being
>> played back in a room must be controlled by or at least known to the
>> audio processing unit sending audio _from_ that room. This is to avoid
>> echo or multi-path problems.
>>
>> One example of such a problem is if a presentation in the form of a
>> movie with a soundtrack is played back on a computer separate from the
>> telepresence system in the room. The microphone system in the room will
>> pick up the sound from the computer's loudspeakers and happily transmit
>> that as voice into the conference. The presentation audio is then
>> delivered to other sites through two different paths with different
>> delays, one of them with poor quality.
>
> This is not a problem of the current protocols, you can send two audio
> streams in SIP and assign a different content attribute to each of them. The
> issue of the local echo of the movie sound to the people audio is a local
> system issue and not a standard issue. As for handling two audio streams
> this will require a definition like H.239 for this case in order to achieve
> interoperability.
>>
>> The other (and totally separate) point I am making is that with CLUE we
>> will have the ability to send presentation audio as a separate stream,
>> and that we are happy about that. Today locally input presentation
>> audio is most often mixed with the mic signal and sent in the main
>> audio stream (which can be stereo). There is no H.239 equivalent for
>> audio.
>
> Sending two separate audio is not a CLUE feature, it can be done by offering
> two audio RTP sessions for example.
>
>>
>> Regards
>> Johan
>>
>>
>>
>> -----Original Message-----
>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]
>> Sent: 2. mai 2012 17:23
>> To: Johan Ludvig Nielsen (johaniel)
>> Cc: Stephen Botzko; CLUE
>> Subject: Re: [clue] ways of managing presentations in telepresence
>> sessions
>>
>> On 5/2/12 8:06 AM, Johan Ludvig Nielsen (johaniel) wrote:
>>> I just want to remind you all that presentation often means video
>>> _and_ audio, for instance a movie clip with a stereo soundtrack.
>>> Sometimes presentation means only audio. Hook up your favourite
>> device
>>
>>> and share a music clip or an interesting recording.
>>>
>>> Any presentation audio played back locally must be controlled by, or
>>> at least be exactly (in sample sync) known to, the local telepresence
>>> system controller. A totally separate endpoint for presentation will
>>> therefore cause some practical problems.
>>>
>>> By the way, one very useful effect of CLUE is the ability for
>>> receiving endpoints to distinguish between audio from live talking
>>> sources and presentations/recordings.
>>
>> I'm not sure I understand the point you are making.
>> Certainly it is true that a presentation may consist of audio and
>> video.
>> But its not just presentations that can contain paired audio and video.
>> When we have many audio and video captures, there could be several
>> pairs.
>>
>> RFC3388 provides a way (a=mid:ls) to indicate when lip sync is
>> required.
>> Do we need more than that? Should advertisements indicate desirable
>> audio/video pairings so that selection can take that into account?
>>
>>      Thanks,
>>      Paul
>>
>>> Johan
>>>
>>> *From:*clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On
>> Behalf
>>
>>> Of *Stephen Botzko
>>> *Sent:* 1. mai 2012 09:11
>>> *To:* Paul Kyzivat
>>> *Cc:* CLUE
>>> *Subject:* Re: [clue] ways of managing presentations in telepresence
>>> sessions
>>>
>>> On Mon, Apr 30, 2012 at 12:56 PM, Paul Kyzivat <pkyzivat@alum.mit.edu
>>> <mailto:pkyzivat@alum.mit.edu>> wrote:
>>>
>>> On 4/28/12 1:18 PM, Stephen Botzko wrote:
>>>
>>> [sb] As I mentioned above, the existing solutions usually include a
>>> screen-scrape application, so you don't have to use a video cable.
>>> This is essentially the same as using Webex for presenting (but not
>>> remote control).
>>>
>>> How are these solutions connected? Does the captured application data
>>> go to the local room controller, or to an MCU in the middle of the TP
>>> session? Or something else?
>>>
>>> [sb] They are normally connected to the local room telepresence
>> system.
>>> Again, the people in the local room also need to see the
>> presentation,
>>
>>> so this is the most direct and also is the most bandwidth efficient
>>> approach. Another aspect is that the rooms can and are used purely
>>> locally (with no remote systems at all), and presentations also need
>>> to work in that situation. BTW I think adding requirements for
>> support
>>
>>> of multiple endpoints in the same room is an unwise path - this is
>> not
>>
>>> SPLICES, and we have enough to do already. I agree with folks who are
>>> saying it is out of scope[/sb]
>>>
>>>        Also, even though Webex allows remote control, in my
>>>        experience that feature is not used as much as simple
>>>        presenting. I am
>>>        not saying it has no value, just that the most common case I
>> see
>>>        is a
>>>        simple presentation.
>>>
>>>    That is my experience as well. I wasn't thinking about the
>>>    multi-user-control aspect.
>>>
>>>        Supporting the video cable still has value, especially if you
>>>        have guest
>>>        presenter who does not have access to your local network.
>> Most
>>>        of those
>>>        presenters are expecting to use a projector, so they have the
>> cables
>>>        with them.
>>>
>>>    Surely. In this case, I presume the cable connects to the local
>> room
>>>    controller. If there are multiple cable connectors (e.g. one at
>> each
>>>    seat) do they show up as multiple presentation streams? Or is
>> there
>>>    some sort of switch and floor control? If so, how does one manage
>>>    the floor control?
>>>
>>>    [sb] Today there is one presenter at a time. With multiple
>> cables,
>>>    there is usually a button at each spot, and if you press it you
>>>    become the presenter (most recent request wins is the policy).
>>>    Normal social courtesies handle conflict, so there is no real
>> need
>>>    for formal floor control. This happens even in ordinary webex
>>>    conferences - if someone grabs the ball when they shouldn't have
>> it,
>>>    people say something and it gets resolved. Similarly, if someone
>>>    needs the ball. More precisely, the presenting video system holds
>>>    the token for the room. With H.239, the MCU (if there is one)
>> grants
>>>    it, using whatever policy it wants, and can revoke it at any
>> time.
>>>    In point-to-point calls, the far end SHALL grant it upon request,
>> so
>>>    in that case the turn-taking policy is mandated in the standard.
>>>    Multiple presenters in the same room is up to the local room
>> policy
>>>    - there is no standard, and in my opinion none is needed. The
>> token
>>>    remains owned by the local video system, it is allowed to present
>>>    whatever local source it wishes. [/sb]
>>>
>>>        My answer on application sharing falling "out of favor"
>> related
>>>        specifically to vendor support for standards-based
>> application
>>>        sharing
>>>        (T.120 in particular) - which I thought was responsive to
>> your
>>>        original
>>>        question. Perhaps I misunderstood it. Anyway there were
>> several
>>>        reasons [and perhaps various viewpoints] on why T.120 was
>> dropped,
>>>        though I think it is probably not a useful discussion for
>> this
>>>        list. I
>>>        know of no other standards-based protocol for application
>> sharing.
>>>
>>>    I wasn't assuming there was, other than a pure video (and maybe
>>>    audio) stream interface. There are other fora for that sort of
>>>    thing, but its my impression that this is largely a world of
>>>    proprietary and defacto standards.
>>>
>>>        BTW, it is relatively common for web screen sharing to
>> co-exist
>>>        with the
>>>        videoconferencing presentation methods. For instance, you can
>> have a
>>>        stand-alone webex conference, with someone sharing their
>> laptop
>>>        screen
>>>        for the video participants.[/sb]
>>>
>>>    I have done this. But it was cumbersome. IIRC, getting the
>> sharing
>>>    to be visible in the room I was in required using a video cable
>> in
>>>    addition to using webex sharing.
>>>
>>> [sb]With our equipment you could use the cable if you wished, but it
>>> would not be required. Though generally speaking, people are used to
>>> using projectors for presenting. Video systems are providing
>> identical
>>
>>> interfaces, so they work the way people expect. For instance, in IETF
>>> interim meetings the Webex screen is always presented locally,
>>> frequently using a cable. The chairs may find that cumbersome, but
>>> they certainly come into the meeting expecting to do it anyway.[\sb]
>>>
>>>        Of course that is still somewhat cumbersome, but presumably
>> it
>> will
>>>        be improved over time. Its the UI for driving it that is
>> cumbersome,
>>>        not the output.
>>>
>>>        A key difference is that if the computer output is via video
>> cable
>>>        into the local room controller, then that is probably
>> responsible
>>>        for displaying it locally on a display in the room as well as
>>>        sending it to the remote end. If the users connect their
>> computers
>>>        directly to the MCU, then the capture will come to the room
>> just
>>>        like anything else from the MCU.
>>>
>>>        [sb]The standard model for videoconferencing presentations is
>> a
>>>        token-controlled transmission. If you don't have the token,
>> you are
>>>        receiving. The local equipment is always responsible for
>> display.
>>>        Looping the presentation back through the MCU back to the
>>>        originating
>>>        site wastes bandwidth.
>>>
>>>        I don't know if web conferencing solutions do this
>> differently
>>>        or not.
>>>        I've always assumed that when I grab the webex "ball" I stop
>>>        receiving
>>>        desktop images. Certainly there is no reason for the server
>> to
>> send
>>>        them back to me.[/sb]
>>>
>>>
>>>    Thanks,
>>>    Paul
>>>
>>
>> _______________________________________________
>> clue mailing list
>> clue@ietf.org
>> https://www.ietf.org/mailman/listinfo/clue
>
> _______________________________________________
> clue mailing list
> clue@ietf.org
> https://www.ietf.org/mailman/listinfo/clue

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




--Apple-Mail=_A0853D9D-013E-4D89-A966-982E6459FB8C-- From marshall.eubanks@gmail.com Fri May 4 08:48:32 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3C1821F8629 for ; Fri, 4 May 2012 08:48:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.654 X-Spam-Level: X-Spam-Status: No, score=-103.654 tagged_above=-999 required=5 tests=[AWL=-0.055, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eqp2mpHh+O-t for ; Fri, 4 May 2012 08:48:31 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9DE5C21F85EF for ; Fri, 4 May 2012 08:48:30 -0700 (PDT) Received: by lagj5 with SMTP id j5so2452377lag.31 for ; Fri, 04 May 2012 08:48:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=IktvdlCXM60YDCFKzkjMT+9WQemR+Z0tr+RNuc+5D5c=; b=fZR0tAGIl8rWfIDc7pfe2iAAcMBVtjHXuzmN8mARCNUMWAhuRqEpHhDBZrhop9AzqU FSGuS7kC4kh2jdZOynTWlCM3djL/gOhDmqx+I5Mwn2viNKUg+eO07Eywtr/3vfg6vZN9 WNNjnz7jDdw4TG22vt84IGzSmrjrDDpVdOfiEfzGfFeEOlcTnIIqTHqGD8sKLjeJ35RX B835nfrot3edKlFavJaZeR2saxuaUXBpFziX7nBFXk49wCXjYVF3rtFNvWeSGsPTHAhs bG4tL90IL5dejNXMw7PX7NSda67ZL25wkhb3+8YparBPawawKzEkvWyu8suj2rFjSh5H r2DA== MIME-Version: 1.0 Received: by 10.112.104.99 with SMTP id gd3mr3342354lbb.70.1336146509267; Fri, 04 May 2012 08:48:29 -0700 (PDT) Received: by 10.112.56.13 with HTTP; Fri, 4 May 2012 08:48:29 -0700 (PDT) In-Reply-To: References: <4F997E6B.7070501@alum.mit.edu> <4F9B0D81.4040608@alum.mit.edu> <4F9EC454.3060605@alum.mit.edu> <05DD269BD82AA549BC4B2619BBAC466A0109F228@XMB-AMS-206.cisco.com> <4FA15144.9030307@alum.mit.edu> <05DD269BD82AA549BC4B2619BBAC466A0109F407@XMB-AMS-206.cisco.com> <4fa295be.0852b40a.771f.1804@mx.google.com> Date: Fri, 4 May 2012 11:48:29 -0400 Message-ID: From: Marshall Eubanks To: Brian Rosen Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: CLUE , "Johan Ludvig Nielsen \(johaniel\)" Subject: Re: [clue] ways of managing presentations in telepresence sessions X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 04 May 2012 15:48:32 -0000 On Fri, May 4, 2012 at 11:02 AM, Brian Rosen wrote: > Sorry, I wasn't clear. > > I'm not proposing to solve the audio problem of prerecorded audio > interacting with room audio. > > I'm observing that in most cases, today, there is a presentation system t= hat > is independent of the audio/video system. =A0Endpoints for both are in th= e > same room. =A0They interact (floor control for example). =A0We don't have= any > way to describe or handle this in CLUE. > As I said on the call, to me our job is to figure out what information is needed, what can realistically be obtained and how to best relay it, and stay out of the rest. Regards Marshall > It's not the same problem as multiple audio or video systems in the same > room either. > > Brian > > On May 4, 2012, at 4:26 AM, Stephen Botzko wrote: > > Of course it is a real problem, it happens every day. The exact same issu= e > occurs with mixes of speaker phones, mobile phones, PCs,=A0 and tradition= al > video conferencing all the time.=A0 The problem is not unique to multi-st= ream > endpoints, and is not made worse by CLUE. > > The only solutions that work are to (a) route the presentation audio outp= ut > into an telepresence room audio input, instead of using built-in speakers= in > the presentation system and (b) disconnect the presentation audio output = and > (c) mute the presentation audio output.=A0 These solutions are physical, = and > do not involve the normal signaling layers we develop in the IETF. > > Detection of the echo/feedback path can in principle be done in the media > plane, though it does add complexity to each endpoint. > > Detecting it through signaling is problematic, since the various devices > involved often use different protocols, and therefore have no common > knowledge of what audio conference they are in.=A0 There are also scenari= os > where the echo/feedback path occurs with independent audio bridges (or no > bridges at all).=A0 And there is no ability to identify that the devices = are > in the same location and that they both have open microphones or speakers= . > > Eliminating the echo/feedback automatically is also challenging, since yo= u > need to identify the best devices to mute, and create a mechanism which c= an > block the problematic signaling path(s).=A0 Such a mechanism can also be > exploited to launch a denial of service attack. > > In my view this is clearly not a CLUE issue, and I don't see much hope fo= r a > workable signaling solution no matter where it is done. > > Stephen Botzko > > On Thu, May 3, 2012 at 11:17 PM, Brian Rosen wrote: >> >> Because it's not a common problem, and there is no right way to do it. >> >> Having the telepresence audio/video on one system and the presentation >> system on another is probably more common that having them on the same >> system. >> >> Brian >> >> On May 3, 2012, at 4:40 PM, Stephen Botzko wrote: >> >> I have two separate speakerphones from two vendors in one room calling >> into the same audio conference.=A0 They interact in a way that utterly f= ails >> to deliver usable audio to phones in other locations.=A0 We don't have >> mechanisms in SIP to represent this or prevent the bad behaviour. >> >> This is a problem for the IETF because???? >> >> Stephen Botzko >> >> On Thu, May 3, 2012 at 6:18 PM, Brian Rosen wrote: >>> >>> I go back to what I see is the fundamental issue: >>> >>> You have two separate systems from two vendors in one room. =A0They >>> interact in a way that is important to other rooms. =A0We don't have >>> mechanisms to represent this. >>> >>> Brian >>> >>> On May 3, 2012, at 10:25 AM, Roni Even wrote: >>> >>> > Hi, >>> > See inline >>> > Roni >>> > >>> >> -----Original Message----- >>> >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf >>> >> Of >>> >> Johan Ludvig Nielsen (johaniel) >>> >> Sent: Thursday, May 03, 2012 4:02 PM >>> >> To: Paul Kyzivat >>> >> Cc: CLUE >>> >> Subject: Re: [clue] ways of managing presentations in telepresence >>> >> sessions >>> >> >>> >> Sorry for being unclear. I am commenting on the implied option of >>> >> rendering presentation on a separate system, either on one or severa= l >>> >> computers or a dedicated endpoint separate from the telepresence >>> >> system >>> >> in the room. >>> >> >>> >> My main point is that all audio belonging to a conference and being >>> >> played back in a room must be controlled by or at least known to the >>> >> audio processing unit sending audio _from_ that room. This is to avo= id >>> >> echo or multi-path problems. >>> >> >>> >> One example of such a problem is if a presentation in the form of a >>> >> movie with a soundtrack is played back on a computer separate from t= he >>> >> telepresence system in the room. The microphone system in the room >>> >> will >>> >> pick up the sound from the computer's loudspeakers and happily >>> >> transmit >>> >> that as voice into the conference. The presentation audio is then >>> >> delivered to other sites through two different paths with different >>> >> delays, one of them with poor quality. >>> > >>> > This is not a problem of the current protocols, you can send two audi= o >>> > streams in SIP and assign a different content attribute to each of >>> > them. The >>> > issue of the local echo of the movie sound to the people audio is a >>> > local >>> > system issue and not a standard issue. As for handling two audio >>> > streams >>> > this will require a definition like H.239 for this case in order to >>> > achieve >>> > interoperability. >>> >> >>> >> The other (and totally separate) point I am making is that with CLUE >>> >> we >>> >> will have the ability to send presentation audio as a separate strea= m, >>> >> and that we are happy about that. Today locally input presentation >>> >> audio is most often mixed with the mic signal and sent in the main >>> >> audio stream (which can be stereo). There is no H.239 equivalent for >>> >> audio. >>> > >>> > Sending two separate audio is not a CLUE feature, it can be done by >>> > offering >>> > two audio RTP sessions for example. >>> > >>> >> >>> >> Regards >>> >> Johan >>> >> >>> >> >>> >> >>> >> -----Original Message----- >>> >> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >>> >> Sent: 2. mai 2012 17:23 >>> >> To: Johan Ludvig Nielsen (johaniel) >>> >> Cc: Stephen Botzko; CLUE >>> >> Subject: Re: [clue] ways of managing presentations in telepresence >>> >> sessions >>> >> >>> >> On 5/2/12 8:06 AM, Johan Ludvig Nielsen (johaniel) wrote: >>> >>> I just want to remind you all that presentation often means video >>> >>> _and_ audio, for instance a movie clip with a stereo soundtrack. >>> >>> Sometimes presentation means only audio. Hook up your favourite >>> >> device >>> >> >>> >>> and share a music clip or an interesting recording. >>> >>> >>> >>> Any presentation audio played back locally must be controlled by, o= r >>> >>> at least be exactly (in sample sync) known to, the local telepresen= ce >>> >>> system controller. A totally separate endpoint for presentation wil= l >>> >>> therefore cause some practical problems. >>> >>> >>> >>> By the way, one very useful effect of CLUE is the ability for >>> >>> receiving endpoints to distinguish between audio from live talking >>> >>> sources and presentations/recordings. >>> >> >>> >> I'm not sure I understand the point you are making. >>> >> Certainly it is true that a presentation may consist of audio and >>> >> video. >>> >> But its not just presentations that can contain paired audio and >>> >> video. >>> >> When we have many audio and video captures, there could be several >>> >> pairs. >>> >> >>> >> RFC3388 provides a way (a=3Dmid:ls) to indicate when lip sync is >>> >> required. >>> >> Do we need more than that? Should advertisements indicate desirable >>> >> audio/video pairings so that selection can take that into account? >>> >> >>> >> =A0 =A0 =A0Thanks, >>> >> =A0 =A0 =A0Paul >>> >> >>> >>> Johan >>> >>> >>> >>> *From:*clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On >>> >> Behalf >>> >> >>> >>> Of *Stephen Botzko >>> >>> *Sent:* 1. mai 2012 09:11 >>> >>> *To:* Paul Kyzivat >>> >>> *Cc:* CLUE >>> >>> *Subject:* Re: [clue] ways of managing presentations in telepresenc= e >>> >>> sessions >>> >>> >>> >>> On Mon, Apr 30, 2012 at 12:56 PM, Paul Kyzivat >> >>> > wrote: >>> >>> >>> >>> On 4/28/12 1:18 PM, Stephen Botzko wrote: >>> >>> >>> >>> [sb] As I mentioned above, the existing solutions usually include a >>> >>> screen-scrape application, so you don't have to use a video cable. >>> >>> This is essentially the same as using Webex for presenting (but not >>> >>> remote control). >>> >>> >>> >>> How are these solutions connected? Does the captured application da= ta >>> >>> go to the local room controller, or to an MCU in the middle of the = TP >>> >>> session? Or something else? >>> >>> >>> >>> [sb] They are normally connected to the local room telepresence >>> >> system. >>> >>> Again, the people in the local room also need to see the >>> >> presentation, >>> >> >>> >>> so this is the most direct and also is the most bandwidth efficient >>> >>> approach. Another aspect is that the rooms can and are used purely >>> >>> locally (with no remote systems at all), and presentations also nee= d >>> >>> to work in that situation. BTW I think adding requirements for >>> >> support >>> >> >>> >>> of multiple endpoints in the same room is an unwise path - this is >>> >> not >>> >> >>> >>> SPLICES, and we have enough to do already. I agree with folks who a= re >>> >>> saying it is out of scope[/sb] >>> >>> >>> >>> =A0 =A0 =A0 =A0Also, even though Webex allows remote control, in my >>> >>> =A0 =A0 =A0 =A0experience that feature is not used as much as simpl= e >>> >>> =A0 =A0 =A0 =A0presenting. I am >>> >>> =A0 =A0 =A0 =A0not saying it has no value, just that the most commo= n case I >>> >> see >>> >>> =A0 =A0 =A0 =A0is a >>> >>> =A0 =A0 =A0 =A0simple presentation. >>> >>> >>> >>> =A0 =A0That is my experience as well. I wasn't thinking about the >>> >>> =A0 =A0multi-user-control aspect. >>> >>> >>> >>> =A0 =A0 =A0 =A0Supporting the video cable still has value, especial= ly if you >>> >>> =A0 =A0 =A0 =A0have guest >>> >>> =A0 =A0 =A0 =A0presenter who does not have access to your local net= work. >>> >> Most >>> >>> =A0 =A0 =A0 =A0of those >>> >>> =A0 =A0 =A0 =A0presenters are expecting to use a projector, so they= have the >>> >> cables >>> >>> =A0 =A0 =A0 =A0with them. >>> >>> >>> >>> =A0 =A0Surely. In this case, I presume the cable connects to the lo= cal >>> >> room >>> >>> =A0 =A0controller. If there are multiple cable connectors (e.g. one= at >>> >> each >>> >>> =A0 =A0seat) do they show up as multiple presentation streams? Or i= s >>> >> there >>> >>> =A0 =A0some sort of switch and floor control? If so, how does one m= anage >>> >>> =A0 =A0the floor control? >>> >>> >>> >>> =A0 =A0[sb] Today there is one presenter at a time. With multiple >>> >> cables, >>> >>> =A0 =A0there is usually a button at each spot, and if you press it = you >>> >>> =A0 =A0become the presenter (most recent request wins is the policy= ). >>> >>> =A0 =A0Normal social courtesies handle conflict, so there is no rea= l >>> >> need >>> >>> =A0 =A0for formal floor control. This happens even in ordinary webe= x >>> >>> =A0 =A0conferences - if someone grabs the ball when they shouldn't = have >>> >> it, >>> >>> =A0 =A0people say something and it gets resolved. Similarly, if som= eone >>> >>> =A0 =A0needs the ball. More precisely, the presenting video system = holds >>> >>> =A0 =A0the token for the room. With H.239, the MCU (if there is one= ) >>> >> grants >>> >>> =A0 =A0it, using whatever policy it wants, and can revoke it at any >>> >> time. >>> >>> =A0 =A0In point-to-point calls, the far end SHALL grant it upon req= uest, >>> >> so >>> >>> =A0 =A0in that case the turn-taking policy is mandated in the stand= ard. >>> >>> =A0 =A0Multiple presenters in the same room is up to the local room >>> >> policy >>> >>> =A0 =A0- there is no standard, and in my opinion none is needed. Th= e >>> >> token >>> >>> =A0 =A0remains owned by the local video system, it is allowed to pr= esent >>> >>> =A0 =A0whatever local source it wishes. [/sb] >>> >>> >>> >>> =A0 =A0 =A0 =A0My answer on application sharing falling "out of fav= or" >>> >> related >>> >>> =A0 =A0 =A0 =A0specifically to vendor support for standards-based >>> >> application >>> >>> =A0 =A0 =A0 =A0sharing >>> >>> =A0 =A0 =A0 =A0(T.120 in particular) - which I thought was responsi= ve to >>> >> your >>> >>> =A0 =A0 =A0 =A0original >>> >>> =A0 =A0 =A0 =A0question. Perhaps I misunderstood it. Anyway there w= ere >>> >> several >>> >>> =A0 =A0 =A0 =A0reasons [and perhaps various viewpoints] on why T.12= 0 was >>> >> dropped, >>> >>> =A0 =A0 =A0 =A0though I think it is probably not a useful discussio= n for >>> >> this >>> >>> =A0 =A0 =A0 =A0list. I >>> >>> =A0 =A0 =A0 =A0know of no other standards-based protocol for applic= ation >>> >> sharing. >>> >>> >>> >>> =A0 =A0I wasn't assuming there was, other than a pure video (and ma= ybe >>> >>> =A0 =A0audio) stream interface. There are other fora for that sort = of >>> >>> =A0 =A0thing, but its my impression that this is largely a world of >>> >>> =A0 =A0proprietary and defacto standards. >>> >>> >>> >>> =A0 =A0 =A0 =A0BTW, it is relatively common for web screen sharing = to >>> >> co-exist >>> >>> =A0 =A0 =A0 =A0with the >>> >>> =A0 =A0 =A0 =A0videoconferencing presentation methods. For instance= , you can >>> >> have a >>> >>> =A0 =A0 =A0 =A0stand-alone webex conference, with someone sharing t= heir >>> >> laptop >>> >>> =A0 =A0 =A0 =A0screen >>> >>> =A0 =A0 =A0 =A0for the video participants.[/sb] >>> >>> >>> >>> =A0 =A0I have done this. But it was cumbersome. IIRC, getting the >>> >> sharing >>> >>> =A0 =A0to be visible in the room I was in required using a video ca= ble >>> >> in >>> >>> =A0 =A0addition to using webex sharing. >>> >>> >>> >>> [sb]With our equipment you could use the cable if you wished, but i= t >>> >>> would not be required. Though generally speaking, people are used t= o >>> >>> using projectors for presenting. Video systems are providing >>> >> identical >>> >> >>> >>> interfaces, so they work the way people expect. For instance, in IE= TF >>> >>> interim meetings the Webex screen is always presented locally, >>> >>> frequently using a cable. The chairs may find that cumbersome, but >>> >>> they certainly come into the meeting expecting to do it anyway.[\sb= ] >>> >>> >>> >>> =A0 =A0 =A0 =A0Of course that is still somewhat cumbersome, but pre= sumably >>> >> it >>> >> will >>> >>> =A0 =A0 =A0 =A0be improved over time. Its the UI for driving it tha= t is >>> >> cumbersome, >>> >>> =A0 =A0 =A0 =A0not the output. >>> >>> >>> >>> =A0 =A0 =A0 =A0A key difference is that if the computer output is v= ia video >>> >> cable >>> >>> =A0 =A0 =A0 =A0into the local room controller, then that is probabl= y >>> >> responsible >>> >>> =A0 =A0 =A0 =A0for displaying it locally on a display in the room a= s well as >>> >>> =A0 =A0 =A0 =A0sending it to the remote end. If the users connect t= heir >>> >> computers >>> >>> =A0 =A0 =A0 =A0directly to the MCU, then the capture will come to t= he room >>> >> just >>> >>> =A0 =A0 =A0 =A0like anything else from the MCU. >>> >>> >>> >>> =A0 =A0 =A0 =A0[sb]The standard model for videoconferencing present= ations is >>> >> a >>> >>> =A0 =A0 =A0 =A0token-controlled transmission. If you don't have the= token, >>> >> you are >>> >>> =A0 =A0 =A0 =A0receiving. The local equipment is always responsible= for >>> >> display. >>> >>> =A0 =A0 =A0 =A0Looping the presentation back through the MCU back t= o the >>> >>> =A0 =A0 =A0 =A0originating >>> >>> =A0 =A0 =A0 =A0site wastes bandwidth. >>> >>> >>> >>> =A0 =A0 =A0 =A0I don't know if web conferencing solutions do this >>> >> differently >>> >>> =A0 =A0 =A0 =A0or not. >>> >>> =A0 =A0 =A0 =A0I've always assumed that when I grab the webex "ball= " I stop >>> >>> =A0 =A0 =A0 =A0receiving >>> >>> =A0 =A0 =A0 =A0desktop images. Certainly there is no reason for the= server >>> >> to >>> >> send >>> >>> =A0 =A0 =A0 =A0them back to me.[/sb] >>> >>> >>> >>> >>> >>> =A0 =A0Thanks, >>> >>> =A0 =A0Paul >>> >>> >>> >> >>> >> _______________________________________________ >>> >> clue mailing list >>> >> clue@ietf.org >>> >> https://www.ietf.org/mailman/listinfo/clue >>> > >>> > _______________________________________________ >>> > clue mailing list >>> > clue@ietf.org >>> > https://www.ietf.org/mailman/listinfo/clue >>> >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >> >> >> > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From Mark.Duckworth@polycom.com Fri May 4 10:36:50 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD36021F85DF for ; Fri, 4 May 2012 10:36:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.165 X-Spam-Level: X-Spam-Status: No, score=-6.165 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Ho80XiwKdLi for ; Fri, 4 May 2012 10:36:50 -0700 (PDT) Received: from Crpehubprd01.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id E171921F85CE for ; Fri, 4 May 2012 10:36:49 -0700 (PDT) Received: from Crpmboxprd01.polycom.com ([fe80::ad68:5a0:c919:66b6]) by Crpehubprd01.polycom.com ([fe80::5efe:10.236.0.158%14]) with mapi; Fri, 4 May 2012 10:36:48 -0700 From: "Duckworth, Mark" To: Paul Kyzivat , "clue@ietf.org" Date: Fri, 4 May 2012 10:36:47 -0700 Thread-Topic: [clue] ways of managing presentations in telepresence sessions Thread-Index: Ac0p+aIkg4LkZld3QdCFlMA6Iw+mQQAIskbw Message-ID: <44C6B6B2D0CF424AA90B6055548D7A6102FD51EEA9@CRPMBOXPRD01.polycom.com> References: <4F997E6B.7070501@alum.mit.edu><4F9B0D81.4040608@alum.mit.edu><4F9EC454.3060605@alum.mit.edu> <05DD269BD82AA549BC4B2619BBAC466A0109F228@XMB-AMS-206.cisco.com> <4FA15144.9030307@alum.mit.edu> <05DD269BD82AA549BC4B2619BBAC466A0109F407@XMB-AMS-206.cisco.com> <4FA2AB5D.7050205@alum.mit.edu> <44C6B6B2D0CF424AA90B6055548D7A6102FD51ED1C@CRPMBOXPRD01.polycom.com> <4FA3D91F.7020008@alum.mit.edu> In-Reply-To: <4FA3D91F.7020008@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [clue] ways of managing presentations in telepresence sessions X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 04 May 2012 17:36:50 -0000 Hi Paul, Comments inline. Mark > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf=20 > Of Paul Kyzivat > Sent: Friday, May 04, 2012 9:27 AM > To: clue@ietf.org > Subject: Re: [clue] ways of managing presentations in telepresence=20 > sessions >=20 > On 5/4/12 9:06 AM, Duckworth, Mark wrote: > > Paul asked: > > " when selecting which capture scene entries and captures to=20 > > receive, > the recipient > > will be able to identify audio/video pairs so that they can=20 > > be selected as > a > > pair?" > > > > Yes, this is one of the functions of capture scenes. If the=20 > > provider is > advertising an audio/video pair, then the provider puts the video in a=20 > capture scene entry and the audio in another capture scene entry and=20 > puts both these capture scene entries into the same capture scene. So=20 > the consumer knows the audio and video are part of the same capture=20 > scene, so the consumer can select them both and render them together. > > > > Mark >=20 > Perhaps that is part of the answer, but maybe not all of it. >=20 > Is it the case that all captures from the same scene should be synchroniz= ed? > (That seems plausible to me.) =20 [Duckworth, Mark] No not always, for example an MCU that creates a scene th= at can have media captures from multiple different endpoints in the same sc= ene. > I guess that suggests that captures from *different* scenes need not=20 > be synchronized. [Duckworth, Mark] Correct. =20 > Suppose there are two presentation video captures and two presentation=20 > audio captures in the same scene. And suppose a receiver can't handle two= . > If it selects one of the videos, how does it select the audio that matche= s it? >=20 > I guess at one level it could attempt to correlate them by spatial=20 > position. Or, perhaps whatever attribute it uses to select one of the=20 > videos can be used to select one of the audios. (I think that falls=20 > back to having additional > attribute(s) to describe the source and/or content of a capture. We've=20 > already discussed that.) [Duckworth, Mark] Yes, the consumer can do that. But I would say a provide= r that is interested in better interoperability with less capable devices w= ould also advertise a capture scene entry with a single video capture and a= nother with a single audio capture if at all possible. >=20 > Thanks, > Paul From mary.ietf.barnes@gmail.com Fri May 4 12:28:04 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A415A21F8620 for ; Fri, 4 May 2012 12:28:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.546 X-Spam-Level: X-Spam-Status: No, score=-103.546 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SDME1cKpPHc0 for ; Fri, 4 May 2012 12:28:04 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id D350721F861A for ; Fri, 4 May 2012 12:28:03 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so2723421vbb.31 for ; Fri, 04 May 2012 12:28:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=DIhMQIwq2jgI2Y57PGWmvzVHTDZ8Z1HmgYyEe3bPsaM=; b=fVO3Y+EytFYwluDIleWswUFvVxSm01PxgOKehqt79Y+jwMRd9504b0IRn3WIKvs96O 49lnJBKx7LFxmcPICa3yWpmfuh0spV6j0Q6slhDZK8z9MS9L0iTqhfcZzf34PinpE9FG EI57fFWArzgMLbWXwu0qhO5ogK1qDuzobVcOgmAhVDfp3gkbPpn6s6AqMpmcF2PGwfDz XprNFy7eQxISW+mc30cpIlk6AuH9AEwM0+8pGZ7qSh6XyDp4ffZrVIURm9Z21Wq9NQ4M maSJMsQNqMGJNtj/MEpLJrcguxHAku4PuBVsjfpk95XoaOEWh0o74+ntyPvlKS2goImn mGIA== MIME-Version: 1.0 Received: by 10.52.68.204 with SMTP id y12mr3667423vdt.53.1336159228295; Fri, 04 May 2012 12:20:28 -0700 (PDT) Received: by 10.52.68.145 with HTTP; Fri, 4 May 2012 12:20:28 -0700 (PDT) In-Reply-To: References: Date: Fri, 4 May 2012 14:20:28 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=20cf307d00dc2a7be204bf3ad033 Subject: Re: [clue] Plans for call - Tuesday, May 1st @ 9am Central X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 04 May 2012 19:28:04 -0000 --20cf307d00dc2a7be204bf3ad033 Content-Type: text/plain; charset=ISO-8859-1 I have posted the minutes from Tuesday's meeting - it includes my rough notes and notes from Jonathan Lennox and John Leslie. I have included a rough summary at the beginning. http://trac.tools.ietf.org/wg/clue/trac/wiki/Design-Team Mary. On Mon, Apr 30, 2012 at 10:19 PM, Mary Barnes wrote: > Hi all, > > We will have a call tomorrow. Let's see if we can get some clarity and > common understanding around the presentation topic that's been under > discussion on the list over the past week: > http://www.ietf.org/mail-archive/web/clue/current/msg01367.html > > Webex info is here: > http://www.ietf.org/mail-archive/web/clue/current/msg01287.html > > Mary. > --20cf307d00dc2a7be204bf3ad033 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I have posted the minutes from Tuesday's meeting - it includes my rough= notes and notes from Jonathan Lennox and John Leslie. =A0I have included a= rough summary at the beginning.

Mary.=A0

On Mon, Apr = 30, 2012 at 10:19 PM, Mary Barnes <mary.ietf.barnes@gmail.com= > wrote:
Hi all,

We will have a ca= ll tomorrow. =A0Let's see if we can get some clarity and common underst= anding around the presentation topic that's been under discussion on th= e list over the past week:


--20cf307d00dc2a7be204bf3ad033-- From mary.ietf.barnes@gmail.com Fri May 4 12:46:05 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C29321F858E for ; Fri, 4 May 2012 12:46:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.547 X-Spam-Level: X-Spam-Status: No, score=-103.547 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KskXpX9ikwng for ; Fri, 4 May 2012 12:46:05 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 03FB821F8585 for ; Fri, 4 May 2012 12:46:04 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so2736398vbb.31 for ; Fri, 04 May 2012 12:46:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=+3M00SxRLKYG2q/5JXuOdsGw+jXy+KeyO/QTs/GLAkE=; b=p8zVz745OizxNevIY9TZ5Y5OtxQwuhg+C/GgUKMW7i/nbtDLFLDZf1QYPMKCezhKOr 8HMEEKkAW3a+nb/yFXettD+G7fkBnAqQ7PSMi3PPfzB+wU2VKrK2G2eBckeSCvDNUeBA N9pRfu/E0/S9iOmmNE2mCZbbKZW4tOg2iMCboO9CnJCnEjD5MOykillk/W8dAgCjU1il IQqR4KKGi/xBGeYrW4PAvSo8RNd0uIm1oVvMCMM2AAygiCgCZvWqCvZUO06Z6mdm6L+6 A5G2/t5hPHknQ3E95FiNOhOoPkvnYUiZVIHBkaCibr2z0WqrdTSZNVd6woYfWTI5T9af sHmQ== MIME-Version: 1.0 Received: by 10.52.67.203 with SMTP id p11mr3657230vdt.13.1336158945863; Fri, 04 May 2012 12:15:45 -0700 (PDT) Received: by 10.52.68.145 with HTTP; Fri, 4 May 2012 12:15:45 -0700 (PDT) Date: Fri, 4 May 2012 14:15:45 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=20cf307f32f054e6b704bf3abfdf Subject: [clue] Wiki Updated with Information for CLUE WG Interim Meeting June, 7-8, 2012 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 04 May 2012 19:46:05 -0000 --20cf307f32f054e6b704bf3abfdf Content-Type: text/plain; charset=ISO-8859-1 Hi all, I have updated the CLUE WG wiki with the information for the upcoming Interim meeting: http://trac.tools.ietf.org/wg/clue/trac/wiki Note, that Magnus has been gracious enough to organize a (self-host) dinner for Thursday evening (June 7). I will update the wiki with the details shortly (along with a doodle link). Regards, Mary. --20cf307f32f054e6b704bf3abfdf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all,

I have updated the CLUE WG wiki with the informa= tion for the upcoming Interim meeting:

Note, that Magnus has been gracious enough to organize = a (self-host) dinner for Thursday evening (June 7). =A0I will update the wi= ki with the details shortly (along with a doodle link). =A0

<= /div>
Regards,
Mary.=A0

--20cf307f32f054e6b704bf3abfdf-- From iesg-secretary@ietf.org Fri May 4 13:41:10 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B55A421F8554; Fri, 4 May 2012 13:41:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.509 X-Spam-Level: X-Spam-Status: No, score=-102.509 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OWVqTMzNdnVL; Fri, 4 May 2012 13:41:10 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03F7A21F84EF; Fri, 4 May 2012 13:41:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IESG Secretary To: IETF Announcement List X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120504204110.17902.27697.idtracker@ietfa.amsl.com> Date: Fri, 04 May 2012 13:41:10 -0700 Cc: clue@ietf.org Subject: [clue] CLUE Working Group Interim Meeting: June 7-8, 2012 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 04 May 2012 20:41:10 -0000 Hi Folks, A face-to-face interim meeting is being scheduled for the CLUE WG. The date and location were selected to allow participants to also attend the W3C WebRTC and IETF RTCWEB meetings the following week. Date: June 7-8, 2012 Location: Kista (near Stockholm) Sweden. Exact location will be announced shortly. Note: it is recommended to select a hotel in the city near a subway station that's on the 11 line (i.e., near T-centralen T Bana) Other details (exact location, agenda and webex information for remote participants) will be posted on the CLUE WG mailing list as soon as they are finalized. The information will also be available on the CLUE WG wiki: http://trac.tools.ietf.org/wg/clue/trac/wiki Regards, Mary Barnes, Paul Kyzivat CLUE WG chairs From mary.ietf.barnes@gmail.com Mon May 7 22:17:52 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34E3321F84B5 for ; Mon, 7 May 2012 22:17:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.567 X-Spam-Level: X-Spam-Status: No, score=-103.567 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nLFmRybEZ0PJ for ; Mon, 7 May 2012 22:17:51 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6CFB821F84AE for ; Mon, 7 May 2012 22:17:48 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so995572vbb.31 for ; Mon, 07 May 2012 22:17:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=mxteLVtl6HJsVQe6kL7NPDylGngX2hJ5b8zoyiiZFck=; b=u/D7zhidVrBkPWRU45zotE/HisFZlE7GEISqt58OCbZCTkVBcBvw6rYj5qVIrxxmZT 4/JbLLU9cPfUoKyI+PF6GkVwIQ4HqrZ5BZ8ntl8exjRt37FcDFrjWJNvwjAKDxWD8Lbu nVpbemsDknetr3aJVvH9dyThkPHbFrTnAbGw33egEbxNCNZRRJ6ByLSbYQ0NB0cSBbML FjsiBJSO8VO8dLrGyIn6qJDWjhKuo33cVq1WOFSD1t3Nfw9ICe8mKWRk2LA9jUifxO5r decHuJNEwcbVnFbxmfPGuS5Tx/a06VjsfIA1tbozIQIRD7uPHPRpswShbo0WAGQc+228 H/NA== MIME-Version: 1.0 Received: by 10.220.150.12 with SMTP id w12mr6874751vcv.39.1336454267656; Mon, 07 May 2012 22:17:47 -0700 (PDT) Received: by 10.52.68.145 with HTTP; Mon, 7 May 2012 22:17:47 -0700 (PDT) Date: Tue, 8 May 2012 00:17:47 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=f46d04389097e1db4804bf7f8182 Subject: [clue] No Meeting on Tuesday, May 8th X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 08 May 2012 05:17:52 -0000 --f46d04389097e1db4804bf7f8182 Content-Type: text/plain; charset=ISO-8859-1 Hi all, We will not have a call this week. Note, that the minutes from last week were uploaded to the wiki: http://trac.tools.ietf.org/wg/clue/trac/wiki/Design-Team It seems we are still discussing the presentation issue from last week. Mary. --f46d04389097e1db4804bf7f8182 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all,

We will not have a call this week. =A0Note, that= the minutes from last week were uploaded to the wiki:

It seems we are still discussing the presentation issue= from last week.=A0

Mary.=A0

<= div>

--f46d04389097e1db4804bf7f8182-- From magnus.westerlund@ericsson.com Tue May 8 08:25:00 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98C7721F84C9 for ; Tue, 8 May 2012 08:25:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.14 X-Spam-Level: X-Spam-Status: No, score=-106.14 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O4+1Nj18ME+7 for ; Tue, 8 May 2012 08:24:59 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 7B59D11E8076 for ; Tue, 8 May 2012 08:24:59 -0700 (PDT) X-AuditID: c1b4fb25-b7b09ae000007d0f-d9-4fa93aca0daa Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id C4.D3.32015.ACA39AF4; Tue, 8 May 2012 17:24:58 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.213.0; Tue, 8 May 2012 17:24:58 +0200 Message-ID: <4FA93AC9.70604@ericsson.com> Date: Tue, 8 May 2012 17:24:57 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: CLUE X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: [clue] CLUE Interim Dinner X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 08 May 2012 15:25:00 -0000 Interim participants, I have booked tables at Ardbeg Embassy in Old Town. This will be a pay for your self dinner. This restaurant I have chosen for multiple reasons. The first is that their menu provides a wide variety of Swedish dishes and dishes based on Swedish ingredients. See the main courses here with English explanations when you click a particular dish: http://www.ardbegembassy.se/menu/varmratter/ The second reason is that they are one of Stockholm's best places to try Swedish micro brewery beer. They of course has an excellent whiskey collection also. I hope you find this interesting and want to join us. However, I need a better estimate of how many that will participate in the dinner so that I can ensure that we have an appropriate sized booking. It will also affect if we need to consider a group menu or not. So please indicate if you plan to participate by the 31st of May. http://www.doodle.com/bfpz6suvnbsqb7dd Restaurant: http://www.ardbegembassy.se/ Location: http://g.co/maps/5uruj 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 pkyzivat@alum.mit.edu Wed May 9 08:51:11 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 750A621F8568 for ; Wed, 9 May 2012 08:51:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.472 X-Spam-Level: X-Spam-Status: No, score=-2.472 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5+wIqRoPibSy for ; Wed, 9 May 2012 08:51:10 -0700 (PDT) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [76.96.62.96]) by ietfa.amsl.com (Postfix) with ESMTP id 7052221F846B for ; Wed, 9 May 2012 08:51:07 -0700 (PDT) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta09.westchester.pa.mail.comcast.net with comcast id 7nm91j0021c6gX859rr7Dl; Wed, 09 May 2012 15:51:07 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta23.westchester.pa.mail.comcast.net with comcast id 7rr71j00j07duvL3jrr77N; Wed, 09 May 2012 15:51:07 +0000 Message-ID: <4FAA926A.9010307@alum.mit.edu> Date: Wed, 09 May 2012 11:51:06 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: CLUE Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [clue] Life-size, 3D hologram-like telepods may revolutionize videoconferencing X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2012 15:51:11 -0000 Should we accommodate holograms in clue? :-) http://www.queensu.ca/news/articles/life-size-3d-hologram-telepods-may-revolutionize-videoconferencing From riccardo.bernardini@uniud.it Wed May 9 09:00:12 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C1DC11E8095 for ; Wed, 9 May 2012 09:00:12 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4BKXb-EHisnL for ; Wed, 9 May 2012 09:00:11 -0700 (PDT) Received: from delivery.uniud.it (mail.uniud.it [158.110.1.210]) by ietfa.amsl.com (Postfix) with ESMTP id 53B1311E80AD for ; Wed, 9 May 2012 09:00:11 -0700 (PDT) Received: from nospam.uniud.it (nospam.uniud.it [158.110.1.213]) by delivery.uniud.it (Postfix) with ESMTP id 10449B730BE for ; Wed, 9 May 2012 18:00:09 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at talitha2.cc.uniud.it Received: from smtp.uniud.it ([158.110.1.136]) by nospam.uniud.it (nospam.uniud.it [158.110.1.213]) (amavisd-new, port 10028) with ESMTP id DYGGpYhnl543 for ; Wed, 9 May 2012 18:00:08 +0200 (CEST) Received: from webmail.uniud.it (webmail2.cc.uniud.it [158.110.1.188]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.uniud.it (Postfix) with ESMTPSA id 68759B0035 for ; Wed, 9 May 2012 18:00:08 +0200 (CEST) Received: from 158.110.27.77 ([158.110.27.77]) by webmail.uniud.it (Horde Framework) with HTTP; Wed, 09 May 2012 18:00:08 +0200 Message-ID: <20120509180008.60611i8ostwe78g8@webmail.uniud.it> Date: Wed, 09 May 2012 18:00:08 +0200 From: Riccardo Bernardini To: clue@ietf.org References: <4FAA926A.9010307@alum.mit.edu> In-Reply-To: <4FAA926A.9010307@alum.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.3.7) Subject: Re: [clue] Life-size, 3D hologram-like telepods may revolutionize videoconferencing X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2012 16:00:12 -0000 Paul Kyzivat ha scritto: > Should we accommodate holograms in clue? :-) Why not? As long as you have the bandwidth... :-) > > http://www.queensu.ca/news/articles/life-size-3d-hologram-telepods-may-revolutionize-videoconferencing > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > -- Riccardo Bernardini DIEGM -- University of Udine via delle Scienze 208 33100 Udine Tel: +39-0432-55-8271 Fax: +39-0432-55-8251 ---------------------------------------------------------------------- SEMEL (SErvizio di Messaging ELettronico) - AINF, Universita' di Udine From christer.holmberg@ericsson.com Wed May 9 12:09:46 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA12711E80CB for ; Wed, 9 May 2012 12:09:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.153 X-Spam-Level: X-Spam-Status: No, score=-6.153 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bN756xGR1X1G for ; Wed, 9 May 2012 12:09:46 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 93B8111E8081 for ; Wed, 9 May 2012 12:09:45 -0700 (PDT) X-AuditID: c1b4fb30-b7c78ae000006de5-84-4faac0f80ffb Authentication-Results: mailgw7.ericsson.se x-tls.subject="/CN=esessmw0247"; auth=fail (cipher=AES128-SHA) Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client CN "esessmw0247", Issuer "esessmw0247" (not verified)) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 1B.20.28133.8F0CAAF4; Wed, 9 May 2012 21:09:44 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.64]) by esessmw0247.eemea.ericsson.se ([153.88.115.93]) with mapi; Wed, 9 May 2012 21:09:44 +0200 From: Christer Holmberg To: Paul Kyzivat , CLUE Date: Wed, 9 May 2012 21:08:32 +0200 Thread-Topic: [clue] Life-size, 3D hologram-like telepods may revolutionize videoconferencing Thread-Index: Ac0t+4+6bwpi//JgTS+HqM5o9TMqcgAG5DEg Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C44001357@ESESSCMS0356.eemea.ericsson.se> References: <4FAA926A.9010307@alum.mit.edu> In-Reply-To: <4FAA926A.9010307@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [clue] Life-size, 3D hologram-like telepods may revolutionize videoconferencing X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2012 19:09:47 -0000 I think people going to the microphone in our meetings should use holograms= . The chairs could then easily make them dissapear when they've used too mu= ch time :) Regards, Christer ________________________________________ From: clue-bounces@ietf.org [clue-bounces@ietf.org] On Behalf Of Paul Kyziv= at [pkyzivat@alum.mit.edu] Sent: Wednesday, May 09, 2012 6:51 PM To: CLUE Subject: [clue] Life-size, 3D hologram-like telepods may revolutionize= videoconferencing Should we accommodate holograms in clue? :-) http://www.queensu.ca/news/articles/life-size-3d-hologram-telepods-may-revo= lutionize-videoconferencing _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue= From marshall.eubanks@gmail.com Wed May 9 19:09:42 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C01249E8006 for ; Wed, 9 May 2012 19:09:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.634 X-Spam-Level: X-Spam-Status: No, score=-103.634 tagged_above=-999 required=5 tests=[AWL=-0.035, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QzTA9LU+ye5C for ; Wed, 9 May 2012 19:09:42 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id C4B279E8004 for ; Wed, 9 May 2012 19:09:41 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so806146lbb.31 for ; Wed, 09 May 2012 19:09:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=g6Rbck9aVO10S91w0e/5t8ugCq6r7IsUjJTEkQn2OBA=; b=m3174jRnDlljrPxvGeQPvxLZKI5JLPTnmam9bSRtB3A+ruN+FN/6rUZ0kN97i0q0NC oAUdajOpTP7xQPkTs2+mBTBwpeyWRbbPneW9EjiYQrGW6VQ5d5nT30jFSuHxareCa0QD /X5dV44+lAUxJEe9l1Wq6ecna4UxgeKtogbTHMAW8YpPQU3IIyVgkZfgXmDoBLEnpGhQ SNNko1c54GO5FrJceS+uIEu9BA9PXtWAzZmh/8taBbkfKjoXSXilzBpBKsuK3c1n2ycg 4+Dif7O6cGILiYFunyI9X4Nns+A4+6H8wkiOmLPorjRP3F0sieDPPyqyBKuFCgYFgGYI B9ig== MIME-Version: 1.0 Received: by 10.152.111.41 with SMTP id if9mr2290519lab.19.1336615780618; Wed, 09 May 2012 19:09:40 -0700 (PDT) Received: by 10.112.56.13 with HTTP; Wed, 9 May 2012 19:09:40 -0700 (PDT) In-Reply-To: <4FAA926A.9010307@alum.mit.edu> References: <4FAA926A.9010307@alum.mit.edu> Date: Wed, 9 May 2012 22:09:40 -0400 Message-ID: From: Marshall Eubanks To: Paul Kyzivat Content-Type: text/plain; charset=ISO-8859-1 Cc: CLUE Subject: Re: [clue] Life-size, 3D hologram-like telepods may revolutionize videoconferencing X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 10 May 2012 02:09:42 -0000 On Wed, May 9, 2012 at 11:51 AM, Paul Kyzivat wrote: > Should we accommodate holograms in clue? :-) > > http://www.queensu.ca/news/articles/life-size-3d-hologram-telepods-may-revolutionize-videoconferencing BTW, here is the paper. http://www.hml.queensu.ca/files/TeleHuman%20CRC.pdf Regards Marshall P.S. This is Pepper's Ghost, not a hologram. > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From stephen.botzko@gmail.com Thu May 10 02:45:35 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5CB921F8680 for ; Thu, 10 May 2012 02:45:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.371 X-Spam-Level: X-Spam-Status: No, score=-3.371 tagged_above=-999 required=5 tests=[AWL=0.227, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rhWJvpkzkZDa for ; Thu, 10 May 2012 02:45:35 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0929021F866C for ; Thu, 10 May 2012 02:45:34 -0700 (PDT) Received: by dacx6 with SMTP id x6so1579691dac.31 for ; Thu, 10 May 2012 02:45:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=o38MCFpkQJAO2ygM/51LUJnd+kXtEr5QqxVXuMi4Ac0=; b=at8zhZ7rgki4RkSxYdv0w31xkm4xJEte01teHZz2zzmonKTZ21zdDQlJms3soQUUDj 5Vk4aZQX5wit4CkAq2GwC6ssroI7WyVYHq2MO+Gm2yiJalAlfxW1MAPKV7uILe9A1a9x OfDfzpebFf6faIIzDy2GJq5wq3jnXTG1S98W1s6A0vKAkqtLPvB7f8IfGmFkUlNIx8dO PTuHIfbhq4kc6O11DcZxJPNGp8OjzlcvnP3DV0NtYLqXDcALpm/5X2lHc5wBi0wO/mfX jYccxLm5HMpVZQ7x/3xaNHMFmyDLUVPSQMjkqa82aE8fFExdI1kWSu6ovg4KVwV7XFf4 B+zg== MIME-Version: 1.0 Received: by 10.68.201.169 with SMTP id kb9mr9154313pbc.101.1336643134505; Thu, 10 May 2012 02:45:34 -0700 (PDT) Received: by 10.68.6.167 with HTTP; Thu, 10 May 2012 02:45:34 -0700 (PDT) In-Reply-To: References: <4FAA926A.9010307@alum.mit.edu> Date: Thu, 10 May 2012 11:45:34 +0200 Message-ID: From: Stephen Botzko To: Marshall Eubanks Content-Type: multipart/alternative; boundary=e89a8ff1c08a39414104bfab7b38 Cc: CLUE Subject: Re: [clue] Life-size, 3D hologram-like telepods may revolutionize videoconferencing X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 10 May 2012 09:45:35 -0000 --e89a8ff1c08a39414104bfab7b38 Content-Type: text/plain; charset=ISO-8859-1 I see no reason to do anything special to handle Pepper's Ghost. Stephen Botzko On Thu, May 10, 2012 at 4:09 AM, Marshall Eubanks < marshall.eubanks@gmail.com> wrote: > On Wed, May 9, 2012 at 11:51 AM, Paul Kyzivat > wrote: > > Should we accommodate holograms in clue? :-) > > > > > http://www.queensu.ca/news/articles/life-size-3d-hologram-telepods-may-revolutionize-videoconferencing > > BTW, here is the paper. > > http://www.hml.queensu.ca/files/TeleHuman%20CRC.pdf > > Regards > Marshall > > P.S. This is Pepper's Ghost, not a hologram. > > > _______________________________________________ > > 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 > --e89a8ff1c08a39414104bfab7b38 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I see no reason to do anything special to handle Pepper's Ghost.
Stephen Botzko

On Thu, May 10, 2012 at 4= :09 AM, Marshall Eubanks <marshall.eubanks@gmail.com> wrote:
On Wed, May 9, 2012 at 11:= 51 AM, Paul Kyzivat <pkyzivat@a= lum.mit.edu> wrote:
> Should we accommodate holograms in clue? :-)
>
> http://www.q= ueensu.ca/news/articles/life-size-3d-hologram-telepods-may-revolutionize-vi= deoconferencing

BTW, here is the paper.

http://www.hml.queensu.ca/files/TeleHuman%20CRC.pdf

Regards
Marshall

P.S. This is Pepper's Ghost, not a hologram.

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

--e89a8ff1c08a39414104bfab7b38-- From keith.drage@alcatel-lucent.com Thu May 10 02:55:51 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 431F121F8697 for ; Thu, 10 May 2012 02:55:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.95 X-Spam-Level: X-Spam-Status: No, score=-109.95 tagged_above=-999 required=5 tests=[AWL=0.298, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DgAmF8xaKgRq for ; Thu, 10 May 2012 02:55:49 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id 6E0D621F8691 for ; Thu, 10 May 2012 02:55:49 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q4A9r6Tn009110 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 10 May 2012 11:55:42 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.45]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Thu, 10 May 2012 11:55:25 +0200 From: "DRAGE, Keith (Keith)" To: Stephen Botzko , Marshall Eubanks Date: Thu, 10 May 2012 11:55:24 +0200 Thread-Topic: [clue] Life-size, 3D hologram-like telepods may revolutionize videoconferencing Thread-Index: Ac0ukazDuizacWpFSIicmK1g4vOp2QAALHXw Message-ID: References: <4FAA926A.9010307@alum.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_EDC0A1AE77C57744B664A310A0B23AE23305FDD2FRMRSSXCHMBSC3d_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Cc: CLUE Subject: Re: [clue] Life-size, 3D hologram-like telepods may revolutionize videoconferencing X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 10 May 2012 09:55:51 -0000 --_000_EDC0A1AE77C57744B664A310A0B23AE23305FDD2FRMRSSXCHMBSC3d_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The only relationship I can see with Pepper's ghost is that both involve pr= ojection. The idea of Pepper's ghost is to provide a projected image that appears eth= ereal because you can still see the background through it. The projector is= at 90 degrees to the audience view and the image appears on a sheet of gla= ss set at 45 degrees to the audience view. Because it is glass, you can sti= ll see action or scenery behind the glass (depending on the level of light = placed there). Keith ________________________________ From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Ste= phen Botzko Sent: 10 May 2012 10:46 To: Marshall Eubanks Cc: CLUE Subject: Re: [clue] Life-size, 3D hologram-like telepods may revolutionize = videoconferencing I see no reason to do anything special to handle Pepper's Ghost. Stephen Botzko On Thu, May 10, 2012 at 4:09 AM, Marshall Eubanks > wrote: On Wed, May 9, 2012 at 11:51 AM, Paul Kyzivat > wrote: > Should we accommodate holograms in clue? :-) > > http://www.queensu.ca/news/articles/life-size-3d-hologram-telepods-may-re= volutionize-videoconferencing BTW, here is the paper. http://www.hml.queensu.ca/files/TeleHuman%20CRC.pdf Regards Marshall P.S. This is Pepper's Ghost, not a hologram. > _______________________________________________ > 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 --_000_EDC0A1AE77C57744B664A310A0B23AE23305FDD2FRMRSSXCHMBSC3d_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The only relationship I can see with Pepper’s ghost is that both involve projection.

 

The idea of Pepper’s ghost is to provide a projected image that appears ethereal because you can still see t= he background through it. The projector is at 90 degrees to the audience view = and the image appears on a sheet of glass set at 45 degrees to the audience vie= w. Because it is glass, you can still see action or scenery behind the glass (dependin= g on the level of light placed there).

 

Keith

 

From:= clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Stephen Botzko
Sent: 10 May 2012 10:46
To: Marshall Eubanks
Cc: CLUE
Subject: Re: [clue] Life-siz= e, 3D hologram-like telepods may revolutionize videoconferencing

 

I see no reason t= o do anything special to handle Pepper's Ghost.

Stephen Botzko

On Thu, May 10, 2012 at 4:09= AM, Marshall Eubanks <marshall.eubanks@gmail.com> wrote:

On Wed, May 9, 2012 at 11:51 AM, Paul Kyzivat <= ;pkyzivat@alum.mit.edu> wrote:<= br> > Should we accommodate holograms in clue? :-)
>
> http://www.queensu.ca/news/articles/life-size-3d-hologram= -telepods-may-revolutionize-videoconferencing<= /p>

BTW, here is the paper.

http://www.hml.queensu.ca/files/TeleHuman%20CRC.pdf

Regards
Marshall

P.S. This is Pepper's Ghost, not a hologram.


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

 

--_000_EDC0A1AE77C57744B664A310A0B23AE23305FDD2FRMRSSXCHMBSC3d_-- From marshall.eubanks@gmail.com Thu May 10 04:54:26 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3243F21F8636 for ; Thu, 10 May 2012 04:54:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.634 X-Spam-Level: X-Spam-Status: No, score=-103.634 tagged_above=-999 required=5 tests=[AWL=-0.035, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f53KESo-qR2s for ; Thu, 10 May 2012 04:54:25 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1EC8021F862F for ; Thu, 10 May 2012 04:54:24 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so1157942lbb.31 for ; Thu, 10 May 2012 04:54:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+1de+cO7Sk5S3kXTpt9LPNhGL35Ak55cl4JKbrvbXts=; b=TDiBYbWetsI/NWJGEs0D8747YW5Hi4ONe2h2gGpgHHV88aCoIQ+uxx17HbrwI2e6cj 3w46Gg7DgowrmkBbShYcm2M6aVF0odlkzaX2Ayx7QUpPzZp4rBQeOysOb75rwW0bLwZr weDJxo0wpczJF6AYK5jgD9LTzos1RVP2D91hVRtoj89Y+eitM4Y5LW7JjYvs6Jqv7A9Z 69M6FgWibwB3Xfom4dKexuS2LVFC1HV6iL0cKvbhFW90duRzLfvD1IXpkON0BEExNv0P HLeySbSNRV9ePSge3ig7F18o9p2S8SH/GgK6/VW22kpfHViAKkPT3MHhuhXkwNsxscwP EjVA== MIME-Version: 1.0 Received: by 10.152.111.41 with SMTP id if9mr3830963lab.19.1336650863906; Thu, 10 May 2012 04:54:23 -0700 (PDT) Received: by 10.112.56.13 with HTTP; Thu, 10 May 2012 04:54:23 -0700 (PDT) In-Reply-To: References: <4FAA926A.9010307@alum.mit.edu> Date: Thu, 10 May 2012 07:54:23 -0400 Message-ID: From: Marshall Eubanks To: Stephen Botzko Content-Type: text/plain; charset=ISO-8859-1 Cc: CLUE Subject: Re: [clue] Life-size, 3D hologram-like telepods may revolutionize videoconferencing X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 10 May 2012 11:54:26 -0000 On Thu, May 10, 2012 at 5:45 AM, Stephen Botzko wrote: > I see no reason to do anything special to handle Pepper's Ghost. > Just to be clear, I would agree. There are other systems on the market (now or previously) that also use Pepper's Ghost (and, annoyingly to me at least, frequently claim it's a hologram). Musion 3D : http://www.eyeliner3d.com/cisco_telepresence_holographic_video_conferencing.html Telepresence Tech : http://www.telepresencetech.com/ and, of course, a certain deceased rapper http://www.forbes.com/sites/crime/2012/05/10/digital-domain-cashes-in-on-hologram-tupac/ all use this technology. >From the standpoint of the bits on the wire, the PG seems pretty irrelevant. Regards Marshall > Stephen Botzko > > > On Thu, May 10, 2012 at 4:09 AM, Marshall Eubanks > wrote: >> >> On Wed, May 9, 2012 at 11:51 AM, Paul Kyzivat >> wrote: >> > Should we accommodate holograms in clue? :-) >> > >> > >> > http://www.queensu.ca/news/articles/life-size-3d-hologram-telepods-may-revolutionize-videoconferencing >> >> BTW, here is the paper. >> >> http://www.hml.queensu.ca/files/TeleHuman%20CRC.pdf >> >> Regards >> Marshall >> >> P.S. This is Pepper's Ghost, not a hologram. >> >> > _______________________________________________ >> > 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 > > From christer.holmberg@ericsson.com Mon May 14 11:04:21 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3ED7D21F8647 for ; Mon, 14 May 2012 11:04:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.157 X-Spam-Level: X-Spam-Status: No, score=-6.157 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kD5UiJsuVqU2 for ; Mon, 14 May 2012 11:04:20 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 5FBCC21F8458 for ; Mon, 14 May 2012 11:04:17 -0700 (PDT) X-AuditID: c1b4fb2d-b7bc5ae00000796a-c2-4fb1492085e1 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id C6.46.31082.02941BF4; Mon, 14 May 2012 20:04:16 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.64]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Mon, 14 May 2012 20:04:16 +0200 From: Christer Holmberg To: "clue@ietf.org" Date: Mon, 14 May 2012 20:04:16 +0200 Thread-Topic: CLUE information transport criteria Thread-Index: AQHNMfv55QSY/nukaUun0kfVLBpL4Q== Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C4400136C@ESESSCMS0356.eemea.ericsson.se> 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== Subject: [clue] CLUE information transport criteria X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 14 May 2012 18:04:21 -0000 Hi, In order to decide what is the best and most suitable transport mechanism f= or CLUE related information, we made a decision to start defining criteria,= and then map the information to that criteria, and it will then hopefully = make it easier to choose transport mechanism (the two main options are of c= ourse in-band and out-of-band transport, but there are different variants o= f those options). The purpose of this e-mail is not to collect the information to be sent, bu= t the *criterias* we will match it against. I would request that we, before we start arguing about whether certain crit= eria is valid or not, I would like people to just throw out their ideas and= suggestions. Of course, if you think that a suggested criteria is unclear,= or should be split into two or more criterias, you can suggest a change. B= ut, again, at this point the idea is not to discuss criteria, but to come u= p with suggestions :) Some initial suggestions from myself: - Whether signaling intermediaries (e.g. SBGs) need to have access to the i= nformation - The expected size of the information to be sent - The expected frequency of the information to be sent - Whether the information is sent during session establishment, mid-session= and/or session termination. - Whether the transport of the information is delay sensitive - Whether the information is sent as a notification, or whether some kind o= f response is needed - Whether the information needs to be delivered reliably (either using a re= liable transport mechanism, and/or some knid of higher-level acknowledgemen= t) - Whether the information is needed by a non-CLUE entity in order to partic= ipate in a CLUE conference Regards, Christer From mary.ietf.barnes@gmail.com Mon May 14 16:12:44 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C2E821F8734 for ; Mon, 14 May 2012 16:12:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.635 X-Spam-Level: X-Spam-Status: No, score=-103.635 tagged_above=-999 required=5 tests=[AWL=-0.037, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ijvZQiuzHWMY for ; Mon, 14 May 2012 16:12:42 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8462021F870E for ; Mon, 14 May 2012 16:12:42 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so6626773vbb.31 for ; Mon, 14 May 2012 16:12:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=Ykc4UKYZZcGb3neqn4otyv6W1tPKv/g/fP0LV486PZM=; b=xF856zIKee0wex+pqvxzwc0IEHXWM4m8jJAJN31q/eE8PRFkyBGqwEsgx2I302rcBO 0OKnY3kjJTOVW7EC8lLPuiewobq0dzSHoe3OuK2rCBo99c/lhVZwu9G5v/p/WwpPqBC9 D7NxITohbhm9h2P7iA+iA0IzrZmxid69n0ZWp/Eo5LLfQe2b/ZHdxCmNGO1A92N1Icgx 9/YZkqQt0+wzH2Rblqc1ODRv0C/k/sWcLUmk87R1jIqahNf5qzN6hCtr2y/WqGealn+K DLqt4bOsQZ5Kul90fkYnUhvNjVUXZd0N+fOK7lpSnIL+Ux7n/t06kRdYMdcBUgJHc0ep C0yQ== MIME-Version: 1.0 Received: by 10.52.97.230 with SMTP id ed6mr1345932vdb.65.1337037161844; Mon, 14 May 2012 16:12:41 -0700 (PDT) Received: by 10.52.68.145 with HTTP; Mon, 14 May 2012 16:12:41 -0700 (PDT) Date: Mon, 14 May 2012 18:12:41 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=20cf307ac4371550b904c0073915 Subject: [clue] No CLUE DT meeting on May 15th X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 14 May 2012 23:12:44 -0000 --20cf307ac4371550b904c0073915 Content-Type: text/plain; charset=ISO-8859-1 Hi folks, The only discussion on the list over the past week has been discussion of 3D holograms, so I don't think there is value in a meeting tomorrow given that there have been no document updates either. There was one recent posting that is important for folks to review and provide feedback on - Christer's categories for evaluating the information that needs to be signaled, which quite oddly is not yet in the archives. I'll forward separately and see if it goes through. If folks could please review that and provide feedback, that would be most helpful. As a reminder, the deadline for the interim for document submissions is May 30th (roughly two weeks time). The chairs need to know by the 25th (one week from Friday) whether you would like agenda time and your plans for updating your docs or submitting new docs. Thanks, Mary. --20cf307ac4371550b904c0073915 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi folks,

The only discussion on the list over the past = week has been discussion of 3D holograms, so I don't think there is val= ue in a meeting tomorrow given that there have been no document updates eit= her. =A0There was one recent posting that is important for folks to review = and provide feedback on - Christer's categories for evaluating the info= rmation that needs to be signaled, which quite oddly is not yet in the arch= ives. =A0I'll forward separately and see if it goes through.

If folks could please review that and provide feedback,= that would be most helpful. =A0

As a reminder, th= e deadline for the interim for document submissions is May 30th (roughly tw= o weeks time). =A0The chairs need to know by the 25th (one week from Friday= ) whether you would like agenda time and your plans for updating your docs = or submitting new docs.


Thanks,
Mary.
--20cf307ac4371550b904c0073915-- From marshall.eubanks@gmail.com Mon May 14 17:27:16 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2E4D21F89AC for ; Mon, 14 May 2012 17:27:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.633 X-Spam-Level: X-Spam-Status: No, score=-103.633 tagged_above=-999 required=5 tests=[AWL=-0.034, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sdBi7SQEunOU for ; Mon, 14 May 2012 17:27:16 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 048DD21F89A2 for ; Mon, 14 May 2012 17:27:15 -0700 (PDT) Received: by lagv3 with SMTP id v3so2819126lag.31 for ; Mon, 14 May 2012 17:27:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=4EwQxyRjdH3UFCeWhB3wzUScI4gEusJOHTZh6oBTnjE=; b=0epHSCQHmWfe9z3nO4gctZnB+vMtG1aon/WsBOC+9p9odwIi8ErkYgtulVvFMkOCvw qT1vPw22PZdYtfzXsrhibJy2D72gO74UDrk0s7hNdd9ixeiH7ewfrcon+JQkXRZtH4W3 VrF3L1UBvZxGqsItQQgQdc243fJxB+7VD9xWFsC0LXBxzal7mqnZPZhw1rpezwys0DL8 DgiaYlXYC5nJBoF2e/XXqitU5t9Kuh9WqNJH7zWzBcEhjJBUJAni1HMZZ3aWNXCRQktp WjPrLnP/2XdhHt7pXGHJihsdBfoNVcwi6+yN+L353VLtZ+wIgfzDjLjzXuWP1OF3BmGM j7hg== MIME-Version: 1.0 Received: by 10.152.128.201 with SMTP id nq9mr462088lab.26.1337041634952; Mon, 14 May 2012 17:27:14 -0700 (PDT) Received: by 10.112.56.13 with HTTP; Mon, 14 May 2012 17:27:14 -0700 (PDT) In-Reply-To: References: Date: Mon, 14 May 2012 20:27:14 -0400 Message-ID: From: Marshall Eubanks To: Mary Barnes Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: CLUE Subject: Re: [clue] No CLUE DT meeting on May 15th X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 15 May 2012 00:27:16 -0000 I fear that you may be creating a self-fulfilling situation - in other words, without a meeting, we won't talk about specific stuff, and so there won't be cause for another meeting. Let's have one next week. There is enough to talk about. Regards Marshall On Mon, May 14, 2012 at 7:12 PM, Mary Barnes w= rote: > Hi folks, > > The only discussion on the list over the past week has been discussion of= 3D > holograms, so I don't think there is value in a meeting tomorrow given th= at > there have been no document updates either. =A0There was one recent posti= ng > that is important for folks to review and provide feedback on - Christer'= s > categories for evaluating the information that needs to be signaled, whic= h > quite oddly is not yet in the archives. =A0I'll forward separately and se= e if > it goes through. > > If folks could please review that and provide feedback, that would be mos= t > helpful. > > As a reminder, the deadline for the interim for document submissions is M= ay > 30th (roughly two weeks time). =A0The chairs need to know by the 25th (on= e > week from Friday) whether you would like agenda time and your plans for > updating your docs or submitting new docs. > > > Thanks, > Mary. > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From mary.ietf.barnes@gmail.com Mon May 14 17:36:10 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E65421F88E2 for ; Mon, 14 May 2012 17:36:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.634 X-Spam-Level: X-Spam-Status: No, score=-103.634 tagged_above=-999 required=5 tests=[AWL=-0.036, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HXqmtSPG0+Pm for ; Mon, 14 May 2012 17:36:09 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5AA4521F853C for ; Mon, 14 May 2012 17:36:09 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so6691201vbb.31 for ; Mon, 14 May 2012 17:36:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=aAFjEhyqSLYLylN7NCgFmwWSUwyuq9cBqb5kKnTgefE=; b=U4OKCWmFPHSEr/gX8D9F2P5KGsVYqK8Xd1arVnJYGHX54ZPh8aZOXFRYSZz143Qc2D pu62lSx0LP8ntyZu9VY0eERDlC87Sp/8c+u5p3Jfm8nV9hHuf0F85hJroS65KGvHtAmM 9wonwD6Ml3HX8FttyZSKdEl13UeeXuwGmCJ47VYhs60Cm89xNLAjF3UkKYOJhzjPN6uc DRY3j4ydKz9pdWvpo6J8oXibtpyOZz7OGo+PZO+LiElEfMg3z3v4FCSFk7H4Q1klP9vL pBn4RHgrMG4jUjatWKxW1Do0HLGTJdNeLr2erqBzZOcGe4xnQmI0IB162bcK3ZSVoGIU s1xA== MIME-Version: 1.0 Received: by 10.220.221.139 with SMTP id ic11mr3945351vcb.74.1337042168811; Mon, 14 May 2012 17:36:08 -0700 (PDT) Received: by 10.52.68.145 with HTTP; Mon, 14 May 2012 17:36:08 -0700 (PDT) In-Reply-To: References: Date: Mon, 14 May 2012 19:36:08 -0500 Message-ID: From: Mary Barnes To: Marshall Eubanks Content-Type: multipart/alternative; boundary=14dae9cdca9185922004c0086371 Cc: CLUE Subject: Re: [clue] No CLUE DT meeting on May 15th X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 15 May 2012 00:36:10 -0000 --14dae9cdca9185922004c0086371 Content-Type: text/plain; charset=ISO-8859-1 If you have topics you think need to be covered, then please do contact the chairs or post to the mailing list. I just don't see the point in having a meeting for the sake of having a meeting. There are still outstanding actions from prior meetings and several of the open issues also require actions to move forward. Regards, Mary. On Mon, May 14, 2012 at 7:27 PM, Marshall Eubanks < marshall.eubanks@gmail.com> wrote: > I fear that you may be creating a self-fulfilling situation - in other > words, without a meeting, we won't talk about specific stuff, > and so there won't be cause for another meeting. > > Let's have one next week. There is enough to talk about. > > Regards > Marshall > > On Mon, May 14, 2012 at 7:12 PM, Mary Barnes > wrote: > > Hi folks, > > > > The only discussion on the list over the past week has been discussion > of 3D > > holograms, so I don't think there is value in a meeting tomorrow given > that > > there have been no document updates either. There was one recent posting > > that is important for folks to review and provide feedback on - > Christer's > > categories for evaluating the information that needs to be signaled, > which > > quite oddly is not yet in the archives. I'll forward separately and see > if > > it goes through. > > > > If folks could please review that and provide feedback, that would be > most > > helpful. > > > > As a reminder, the deadline for the interim for document submissions is > May > > 30th (roughly two weeks time). The chairs need to know by the 25th (one > > week from Friday) whether you would like agenda time and your plans for > > updating your docs or submitting new docs. > > > > > > Thanks, > > Mary. > > > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue > > > --14dae9cdca9185922004c0086371 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable If you have topics you think need to be covered, then please do contact the= chairs or post to the mailing list. =A0I just don't see the point in h= aving a meeting for the sake of having a meeting. =A0There are still outsta= nding actions from prior meetings and several of the open issues also requi= re actions to move forward. =A0

Regards,
Mary.

O= n Mon, May 14, 2012 at 7:27 PM, Marshall Eubanks <marshall.eubank= s@gmail.com> wrote:
I fear that you may be creating a self-fulfi= lling situation - in other
words, without a meeting, we won't talk about specific stuff,
and so there won't be cause for another meeting.

Let's have one next week. There is enough to talk about.

Regards
Marshall

On Mon, May 14, 2012 at 7:12 PM, Mary Barnes <mary.ietf.barnes@gmail.com> wrote:
> Hi folks,
>
> The only discussion on the list over the past week has been discussion= of 3D
> holograms, so I don't think there is value in a meeting tomorrow g= iven that
> there have been no document updates either. =A0There was one recent po= sting
> that is important for folks to review and provide feedback on - Christ= er's
> categories for evaluating the information that needs to be signaled, w= hich
> quite oddly is not yet in the archives. =A0I'll forward separately= and see if
> it goes through.
>
> If folks could please review that and provide feedback, that would be = most
> helpful.
>
> As a reminder, the deadline for the interim for document submissions i= s May
> 30th (roughly two weeks time). =A0The chairs need to know by the 25th = (one
> week from Friday) whether you would like agenda time and your plans fo= r
> updating your docs or submitting new docs.
>
>
> Thanks,
> Mary.
>
> _______________________________________________
> clue mailing list
> clue@ietf.org
> https://www.ietf.org/mailman/listinfo/clue
>

--14dae9cdca9185922004c0086371-- From ron.even.tlv@gmail.com Tue May 15 06:28:36 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AFDF21F89A6 for ; Tue, 15 May 2012 06:28:36 -0700 (PDT) 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=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p-FiuWC34sfP for ; Tue, 15 May 2012 06:28:35 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 684A221F8983 for ; Tue, 15 May 2012 06:28:35 -0700 (PDT) Received: by wibhn6 with SMTP id hn6so3058920wib.13 for ; Tue, 15 May 2012 06:28:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language; bh=kcvoGJb6gjAhBgKdhpG+dCJ1nKfa9MPbIM0DEDX82iU=; b=D2xKIkhZhiLKVX6i3UVYYSyo1lP4Yb30BqIV4a6kTXxuAs36mTgQhoBl64mqXiBGxH TtzurqYVT2VoTKdJKl5yXpXH9yiZTaYqTHXAE0GOqIrmS3DbutgVGZsw1XQ8q8eZJAIF 6WFGOpAuERhGMliqiUDpUwJ+D6sA955/RRAQJXsSImEgOB5E2aWd0XIAwpE47Irmhre7 ZK24pKL9LYoTB4EcuK3gPPaMe4kWpDIDnNLrzMtkxU3NOsH5wR2CRkgLQnDronP3k9g3 v2B3eGIBF5O/HeKvQDwsKiinBWQ7Gj4CHmFeXQ4GehICIGzQJZt0eeG6os385HoDtqHY y0vg== Received: by 10.180.77.4 with SMTP id o4mr14702832wiw.17.1337088514496; Tue, 15 May 2012 06:28:34 -0700 (PDT) Received: from windows8d787f9 (bzq-79-177-198-116.red.bezeqint.net. [79.177.198.116]) by mx.google.com with ESMTPS id eb8sm6446421wib.11.2012.05.15.06.28.31 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 15 May 2012 06:28:32 -0700 (PDT) From: "Roni Even" To: "'Christer Holmberg'" , References: <7F2072F1E0DE894DA4B517B93C6A05852C4400136C@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C4400136C@ESESSCMS0356.eemea.ericsson.se> Date: Tue, 15 May 2012 16:26:10 +0300 Message-ID: <4fb25a00.a861b40a.433b.5537@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: AQHNMfv55QSY/nukaUun0kfVLBpL4ZbK14gg Content-Language: en-us Subject: Re: [clue] CLUE information transport criteria X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 15 May 2012 13:28:36 -0000 Hi, Thanks for starting here are some more Whether the CLUE information and the media description (SDP) need to be in the same message. Whether the CLUE information and the media description (SDP) need to use the same transport path. Whether the CLUE information is using one transport (E.g encoding group and MC are using the same transport / message) Roni > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Christer Holmberg > Sent: Monday, May 14, 2012 9:04 PM > To: clue@ietf.org > Subject: [clue] CLUE information transport criteria > > Hi, > > In order to decide what is the best and most suitable transport > mechanism for CLUE related information, we made a decision to start > defining criteria, and then map the information to that criteria, and > it will then hopefully make it easier to choose transport mechanism > (the two main options are of course in-band and out-of-band transport, > but there are different variants of those options). > > The purpose of this e-mail is not to collect the information to be > sent, but the *criterias* we will match it against. > > I would request that we, before we start arguing about whether certain > criteria is valid or not, I would like people to just throw out their > ideas and suggestions. Of course, if you think that a suggested > criteria is unclear, or should be split into two or more criterias, you > can suggest a change. But, again, at this point the idea is not to > discuss criteria, but to come up with suggestions :) > > Some initial suggestions from myself: > > - Whether signaling intermediaries (e.g. SBGs) need to have access to > the information > - The expected size of the information to be sent > - The expected frequency of the information to be sent > - Whether the information is sent during session establishment, mid- > session and/or session termination. > - Whether the transport of the information is delay sensitive > - Whether the information is sent as a notification, or whether some > kind of response is needed > - Whether the information needs to be delivered reliably (either using > a reliable transport mechanism, and/or some knid of higher-level > acknowledgement) > - Whether the information is needed by a non-CLUE entity in order to > participate in a CLUE conference > > Regards, > > Christer > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From christer.holmberg@ericsson.com Tue May 15 07:48:40 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EA8F21F8721 for ; Tue, 15 May 2012 07:48:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.163 X-Spam-Level: X-Spam-Status: No, score=-6.163 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B22trvW5-tU2 for ; Tue, 15 May 2012 07:48:39 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 18E2721F871E for ; Tue, 15 May 2012 07:48:38 -0700 (PDT) X-AuditID: c1b4fb2d-b7bbfae000005e4b-45-4fb26cc64fb4 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 6A.B4.24139.6CC62BF4; Tue, 15 May 2012 16:48:38 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.64]) by esessmw0247.eemea.ericsson.se ([153.88.115.93]) with mapi; Tue, 15 May 2012 16:48:34 +0200 From: Christer Holmberg To: Roni Even , "clue@ietf.org" Date: Tue, 15 May 2012 16:48:33 +0200 Thread-Topic: [clue] CLUE information transport criteria Thread-Index: AQHNMfv55QSY/nukaUun0kfVLBpL4ZbK14gggAAWAoU= Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C44001370@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05852C4400136C@ESESSCMS0356.eemea.ericsson.se>, <4fb25a00.a861b40a.433b.5537@mx.google.com> In-Reply-To: <4fb25a00.a861b40a.433b.5537@mx.google.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [clue] CLUE information transport criteria X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 15 May 2012 14:48:40 -0000 Hi Roni, Thanks for your input! I will *not* discuss your suggestions, simply ask for some clarification on= a couple :) > Whether the CLUE information and the media description (SDP) need to use = the same transport path. If you send CLUE information and SDP in the same SIP message, they will obv= iously take the same path. However, if the SDP is sent in the INVITE, based on which entities insert t= hemself in the route set the subsequent SIP messages (including those that = contain may CLUE information) will not necessarily take the same path as th= e INVITE. So, I think this needs a little clarification. OR, do you mean that SIP could not be used to send CLUE information (and, o= bviously not SDP) in the first place if it matches this criteria? > Whether the CLUE information is using one transport (E.g encoding group a= nd MC are using the same=20 > transport / message) Do you mean to say: whether a piece of CLUE information needs to be sent in= the same message, and/or using the same transport, as another piece of CLU= E information? Regards, Christer > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Christer Holmberg > Sent: Monday, May 14, 2012 9:04 PM > To: clue@ietf.org > Subject: [clue] CLUE information transport criteria > > Hi, > > In order to decide what is the best and most suitable transport > mechanism for CLUE related information, we made a decision to start > defining criteria, and then map the information to that criteria, and > it will then hopefully make it easier to choose transport mechanism > (the two main options are of course in-band and out-of-band transport, > but there are different variants of those options). > > The purpose of this e-mail is not to collect the information to be > sent, but the *criterias* we will match it against. > > I would request that we, before we start arguing about whether certain > criteria is valid or not, I would like people to just throw out their > ideas and suggestions. Of course, if you think that a suggested > criteria is unclear, or should be split into two or more criterias, you > can suggest a change. But, again, at this point the idea is not to > discuss criteria, but to come up with suggestions :) > > Some initial suggestions from myself: > > - Whether signaling intermediaries (e.g. SBGs) need to have access to > the information > - The expected size of the information to be sent > - The expected frequency of the information to be sent > - Whether the information is sent during session establishment, mid- > session and/or session termination. > - Whether the transport of the information is delay sensitive > - Whether the information is sent as a notification, or whether some > kind of response is needed > - Whether the information needs to be delivered reliably (either using > a reliable transport mechanism, and/or some knid of higher-level > acknowledgement) > - Whether the information is needed by a non-CLUE entity in order to > participate in a CLUE conference > > Regards, > > Christer > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue= From trac+clue@trac.tools.ietf.org Tue May 15 08:14:10 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B6AC21F86E4 for ; Tue, 15 May 2012 08:14:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vJepOY9yfNZH for ; Tue, 15 May 2012 08:14:09 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 9002E21F86E0 for ; Tue, 15 May 2012 08:14:09 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1SUJRp-0005Ko-CB; Tue, 15 May 2012 11:14:01 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "clue issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: mary.ietf.barnes@gmail.com X-Trac-Project: clue Date: Tue, 15 May 2012 15:14:01 -0000 X-URL: http://tools.ietf.org/wg/clue/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/clue/trac/ticket/1#comment:1 Message-ID: <078.11f6003b9ac049d8962a9d72951b8bc0@trac.tools.ietf.org> References: <063.f447b18f549ba1007355125cf872394b@trac.tools.ietf.org> X-Trac-Ticket-ID: 1 In-Reply-To: <063.f447b18f549ba1007355125cf872394b@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: mary.ietf.barnes@gmail.com, jonathan@vidyo.com, clue@ietf.org X-SA-Exim-Mail-From: trac+clue@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Cc: jonathan@vidyo.com, clue@ietf.org Subject: Re: [clue] #1: Source Selection Use Case X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2012 15:14:10 -0000 #1: Source Selection Use Case Changes (by mary.ietf.barnes@…): * status: new => closed * resolution: => fixed Old description: > Jonathan Lennox to post Source Selection Use Case on List (by 11/28) New description: Jonathan Lennox to post Source Selection Use Case on List (by 11/28). Per the minutes from the April 10th Design Team meeting (available on the wiki), this use case is deemed out of scope for the first version of CLUE. -- -- ------------------------------------+------------------------------ Reporter: pkyzivat@… | Owner: Jonathan Lennox Type: enhancement | Status: closed Priority: major | Milestone: Component: telepresence-use-cases | Version: Severity: Active WG Document | Resolution: fixed Keywords: | ------------------------------------+------------------------------ Ticket URL: clue From trac+clue@trac.tools.ietf.org Tue May 15 08:17:40 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E4B221F85B6 for ; Tue, 15 May 2012 08:17:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_41=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9XjccIoVtR1R for ; Tue, 15 May 2012 08:17:39 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id B0C5B21F8592 for ; Tue, 15 May 2012 08:17:39 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1SUJVB-0006j0-JT; Tue, 15 May 2012 11:17:29 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "clue issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-clue-framework@tools.ietf.org, mary.ietf.barnes@gmail.com X-Trac-Project: clue Date: Tue, 15 May 2012 15:17:29 -0000 X-URL: http://tools.ietf.org/wg/clue/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/clue/trac/ticket/5#comment:3 Message-ID: <078.bbd959b03a6437ce7e09ed503203c35e@trac.tools.ietf.org> References: <063.a37bc5dd4fc60cc1fce0e69ad3a0e316@trac.tools.ietf.org> X-Trac-Ticket-ID: 5 In-Reply-To: <063.a37bc5dd4fc60cc1fce0e69ad3a0e316@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-clue-framework@tools.ietf.org, mary.ietf.barnes@gmail.com, Stephan@vidyo.com, clue@ietf.org X-SA-Exim-Mail-From: trac+clue@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20120515151739.B0C5B21F8592@ietfa.amsl.com> Resent-Date: Tue, 15 May 2012 08:17:39 -0700 (PDT) Resent-From: trac+clue@trac.tools.ietf.org Cc: Stephan@vidyo.com, clue@ietf.org Subject: Re: [clue] #5: Describing composed captures X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2012 15:17:40 -0000 #5: Describing composed captures Description changed by mary.ietf.barnes@…: Old description: > Stephan Wenger to make proposal for describing composed captures, by mid > December, 2011. > > Update: Stephan made the following proposal: http://www.ietf.org/mail- > archive/web/clue/current/msg00765.html > > Need addt'l WG feedback on this proposal. New description: Stephan Wenger to make proposal for describing composed captures, by mid December, 2011. Update: Stephan made the following proposal: http://www.ietf.org/mail- archive/web/clue/current/msg00765.html Need addt'l WG feedback on this proposal. Based on discussion at April 10th design team meeting (per minutes on wiki), we need to wait until Issue #8 and the new Issue #10 (agreed to be opened at the April 10th meeting. -- -- --------------------------------+------------------------------------------ Reporter: pkyzivat@… | Owner: draft-ietf-clue-framework@… Type: task | Status: new Priority: major | Milestone: Component: framework | Version: Severity: Active WG Document | Resolution: Keywords: | --------------------------------+------------------------------------------ Ticket URL: clue From trac+clue@trac.tools.ietf.org Tue May 15 08:38:52 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92C3521F883A for ; Tue, 15 May 2012 08:38:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.499 X-Spam-Level: X-Spam-Status: No, score=-102.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IVz0lC6pX9ah for ; Tue, 15 May 2012 08:38:51 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id B358B21F87FF for ; Tue, 15 May 2012 08:38:51 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1SUJpj-000843-F4; Tue, 15 May 2012 11:38:43 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "clue issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-clue-framework@tools.ietf.org, mary.ietf.barnes@gmail.com X-Trac-Project: clue Date: Tue, 15 May 2012 15:38:42 -0000 X-URL: http://tools.ietf.org/wg/clue/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/clue/trac/ticket/10 Message-ID: <068.4cb6a3306e2827b0b069460ea300fe83@trac.tools.ietf.org> X-Trac-Ticket-ID: 10 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-clue-framework@tools.ietf.org, mary.ietf.barnes@gmail.com, clue@ietf.org X-SA-Exim-Mail-From: trac+clue@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20120515153851.B358B21F87FF@ietfa.amsl.com> Resent-Date: Tue, 15 May 2012 08:38:51 -0700 (PDT) Resent-From: trac+clue@trac.tools.ietf.org Cc: clue@ietf.org Subject: [clue] #10: Does framework provide sufficient info for the receiver? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2012 15:38:52 -0000 #10: Does framework provide sufficient info for the receiver? This is related to the issues that were discussed at the April 10th (2012) design team meeting: - is there a need for human readable text to differentiate between multiple capture scenes? - more generally does the receiver have sufficient information to select and map what it has received? [Note: issue #8 is somewhat related as it deals with how the receiver differentiates between multiple capture scenes.] Paul sent a summary of the issue: http://www.ietf.org/mail-archive/web/clue/current/msg01293.html Espen sent a summary of the use cases that he believes are supported or not supported with current framework: http://www.ietf.org/mail-archive/web/clue/current/msg01299.html -- --------------------------------+----------------------------------------- Reporter: mary.ietf.barnes@… | Owner: draft-ietf-clue-framework@… Type: defect | Status: new Priority: major | Milestone: milestone1 Component: framework | Version: Severity: Active WG Document | Keywords: --------------------------------+----------------------------------------- Ticket URL: clue From trac+clue@trac.tools.ietf.org Tue May 15 08:49:47 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF2FD21F8704 for ; Tue, 15 May 2012 08:49:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.524 X-Spam-Level: X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mSkSOnnc1KR0 for ; Tue, 15 May 2012 08:49:47 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 661B721F86E3 for ; Tue, 15 May 2012 08:49:46 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1SUK0I-0007TF-Kr; Tue, 15 May 2012 11:49:38 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "clue issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-clue-framework@tools.ietf.org, mary.ietf.barnes@gmail.com X-Trac-Project: clue Date: Tue, 15 May 2012 15:49:38 -0000 X-URL: http://tools.ietf.org/wg/clue/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/clue/trac/ticket/10#comment:1 Message-ID: <083.a7aef13ba747fd6ea11ca0617e2bad0a@trac.tools.ietf.org> References: <068.4cb6a3306e2827b0b069460ea300fe83@trac.tools.ietf.org> X-Trac-Ticket-ID: 10 In-Reply-To: <068.4cb6a3306e2827b0b069460ea300fe83@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-clue-framework@tools.ietf.org, mary.ietf.barnes@gmail.com, clue@ietf.org X-SA-Exim-Mail-From: trac+clue@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20120515154947.661B721F86E3@ietfa.amsl.com> Resent-Date: Tue, 15 May 2012 08:49:46 -0700 (PDT) Resent-From: trac+clue@trac.tools.ietf.org Cc: clue@ietf.org Subject: Re: [clue] #10: Does framework provide sufficient info for the receiver? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2012 15:49:48 -0000 #10: Does framework provide sufficient info for the receiver? Changes (by mary.ietf.barnes@…): * type: defect => task -- --------------------------------+------------------------------------------ Reporter: mary.ietf.barnes@… | Owner: draft-ietf-clue-framework@… Type: task | Status: new Priority: major | Milestone: milestone1 Component: framework | Version: Severity: Active WG Document | Resolution: Keywords: | --------------------------------+------------------------------------------ Ticket URL: clue From michael.hammer@yaanatech.com Tue May 15 09:25:42 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 994DF21F898B for ; Tue, 15 May 2012 09:25:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RX0kEDOl6vMR for ; Tue, 15 May 2012 09:25:41 -0700 (PDT) Received: from email1.corp.yaanatech.com (email1.corp.yaanatech.com [205.140.198.134]) by ietfa.amsl.com (Postfix) with ESMTP id B8B4E21F86E1 for ; Tue, 15 May 2012 09:25:41 -0700 (PDT) Received: from EX2K10MB1.corp.yaanatech.com ([fe80::5568:c31d:f64a:f66a]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.01.0218.012; Tue, 15 May 2012 09:25:41 -0700 From: Michael Hammer To: "christer.holmberg@ericsson.com" , "ron.even.tlv@gmail.com" , "clue@ietf.org" Thread-Topic: [clue] CLUE information transport criteria Thread-Index: AQHNMfv55QSY/nukaUun0kfVLBpL4ZbK14gggAAWAoWAABsLUA== Date: Tue, 15 May 2012 16:25:39 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB38ABB21@EX2K10MB1.corp.yaanatech.com> References: <7F2072F1E0DE894DA4B517B93C6A05852C4400136C@ESESSCMS0356.eemea.ericsson.se>, <4fb25a00.a861b40a.433b.5537@mx.google.com> <7F2072F1E0DE894DA4B517B93C6A05852C44001370@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C44001370@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.88.13] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0008_01CD3295.D6512350" MIME-Version: 1.0 Subject: Re: [clue] CLUE information transport criteria X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 15 May 2012 16:25:42 -0000 ------=_NextPart_000_0008_01CD3295.D6512350 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Christer, Too add on here. To support CLUE exchanges: When one says transport, I think of the question of TCP v. UDP v. SCTP? As far as packaging: Is it bundled into SDP or some other package/MIME type? As for as signaling: Is it carried by SIP and thus have the same route set, or does it use some other signal type with its own route set? (modulo the capability of SIP to have proxies leave them out of route set) Separately, assuming SIP, does it use INVITES or some other message type to carry? Independent of INVITE or something else, must the exchange be coincident with: - SDP media capability discovery (SDP and CLUE exchanges are independent and in stages) - SIP session establishment (could CLUE be setup up before or after the SIP session). (determine endpoint patterns and select media type later, i.e. pre-configured with/without SDP) Mike -----Original Message----- From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Christer Holmberg Sent: Tuesday, May 15, 2012 10:49 AM To: Roni Even; clue@ietf.org Subject: Re: [clue] CLUE information transport criteria Hi Roni, Thanks for your input! I will *not* discuss your suggestions, simply ask for some clarification on a couple :) > Whether the CLUE information and the media description (SDP) need to use the same transport path. If you send CLUE information and SDP in the same SIP message, they will obviously take the same path. However, if the SDP is sent in the INVITE, based on which entities insert themself in the route set the subsequent SIP messages (including those that contain may CLUE information) will not necessarily take the same path as the INVITE. So, I think this needs a little clarification. OR, do you mean that SIP could not be used to send CLUE information (and, obviously not SDP) in the first place if it matches this criteria? > Whether the CLUE information is using one transport (E.g encoding > group and MC are using the same transport / message) Do you mean to say: whether a piece of CLUE information needs to be sent in the same message, and/or using the same transport, as another piece of CLUE information? Regards, Christer > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf > Of Christer Holmberg > Sent: Monday, May 14, 2012 9:04 PM > To: clue@ietf.org > Subject: [clue] CLUE information transport criteria > > Hi, > > In order to decide what is the best and most suitable transport > mechanism for CLUE related information, we made a decision to start > defining criteria, and then map the information to that criteria, and > it will then hopefully make it easier to choose transport mechanism > (the two main options are of course in-band and out-of-band transport, > but there are different variants of those options). > > The purpose of this e-mail is not to collect the information to be > sent, but the *criterias* we will match it against. > > I would request that we, before we start arguing about whether certain > criteria is valid or not, I would like people to just throw out their > ideas and suggestions. Of course, if you think that a suggested > criteria is unclear, or should be split into two or more criterias, > you can suggest a change. But, again, at this point the idea is not to > discuss criteria, but to come up with suggestions :) > > Some initial suggestions from myself: > > - Whether signaling intermediaries (e.g. SBGs) need to have access to > the information > - The expected size of the information to be sent > - The expected frequency of the information to be sent > - Whether the information is sent during session establishment, mid- > session and/or session termination. > - Whether the transport of the information is delay sensitive > - Whether the information is sent as a notification, or whether some > kind of response is needed > - Whether the information needs to be delivered reliably (either using > a reliable transport mechanism, and/or some knid of higher-level > acknowledgement) > - Whether the information is needed by a non-CLUE entity in order to > participate in a CLUE conference > > Regards, > > Christer > _______________________________________________ > 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_000_0008_01CD3295.D6512350 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIP6zCCBBow ggMCAhEAi1t1VoRUhQsAz684SM6xpDANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNOTkxMDAxMDAwMDAwWhcNMzYwNzE2MjM1OTU5WjCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDd hNS5tPmn2PMEeJzePdxsExbZet0kUWbAxyZZDawGCMKU0TMf8IM1H24byN6qbhVOVCfvxG0a7Avj DvBEpVfHQFgeo0cfcexg9m2UyBg57f5CGFbf5ExJEHhOAXY1YxI23Wa8AQQ2o1Vo1aI2CayrISZU Bq0/yhTgrMqtBh2V4vid8eBg/8J/dStMzNr+h5kh6rr+PlTX0ll42zxuz6ATABq4J6HkvmeWyqDF s5zdyXWe6zCaX6PN2a54GT8j6VzbKb2tVcgbVIxj9uim6sc3ElyjKR4C2dsfO7TXD1ZHgRUESq+D J9HFWIjB3faqp6MY2miqbRFR4b9la5+WdtE9AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAKtmjdez useatuZV0AXxnzGNWqrZqkYmD3Htpa1TVmIBRypE6f4/dAsTm7n0TRuy0V+yttKIXLOfzcvUp9lg lYQ6+ME3HWHK57DF5ZHaVKasMYGul97NCKy4wJeAf25ypOdpE5VlH8STPP15jwTUPk/q957OzWd8 T2UC/5GFVHPH/zb3hi3s0F5P/xGfcgbWuBrxTA0mZeJEgB7Hn+Pd6Ara7KUggGlooU9+4WvPB0H6 g468ON2wLhGxa7JCzJq8+UgieUoZD7IcPiB02WrDvvIoeBNWeU9tUOobsLVXsTdmWCPz3A/fCofE 74YF1TgUYJmjS94GlnEs8tu2H6TvP+4wggTXMIIDv6ADAgECAhBcX1ns/Jl/DtI19/BXCcuBMA0G CSqGSIb3DQEBBQUAMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBo dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBW YWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVy IENBIC0gRzMwHhcNMTIwNDAzMDAwMDAwWhcNMTMwNDAzMjM1OTU5WjCCAR4xFzAVBgNVBAoTDlZl cmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13 d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChj KTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNDAyBgNVBAsTK0RpZ2l0YWwgSUQg Q2xhc3MgMSAtIE1pY3Jvc29mdCBGdWxsIFNlcnZpY2UxFzAVBgNVBAMUDk1pY2hhZWwgSGFtbWVy MSswKQYJKoZIhvcNAQkBFhxtaWNoYWVsLmhhbW1lckB5YWFuYXRlY2guY29tMIGfMA0GCSqGSIb3 DQEBAQUAA4GNADCBiQKBgQDoKTk9rP/4lG6CLqIR4++IFTuOSLF6bmhDr6eiSahqU0VNP+H/LbiD MAZsK9GQoBYPKQdKzy/gM+fl3Gm6VOdjKl8M3GB6LGgAK8d3ETN5dyKe5CAG7EEbKg9wxHWcuXW7 KYd052ven5Ec+Xj++v3HsE423O5q2mNh1Q8FNsnlXQIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYD VR0gBD0wOzA5BgtghkgBhvhFAQcXATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2ln bi5jb20vcnBhMAsGA1UdDwQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYD VR0fBEkwRzBFoEOgQYY/aHR0cDovL2luZGMxZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20v SW5kQzFEaWdpdGFsSUQtRzMuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQA8rhDezFsw7OlR3+mZOZ39 SCKWNJ4gMlQEe31NNtvs6BUzE1uN+fJeZrJ5zjTdJWeG1NgVugcuzQfdv/m5BYbhgJvNfW6ElqZh cye6imOUx8diekkeHXKYSLnEvCdJItXsC1h/huIT9e83WksM92qI/TFyCq6u39cGf9PaBYbcKcZk jHjNi3SPnGifMC6opGiiyK/vB1lituoBRcJ13Y7XoXA8T0kSR8Dtmqvo1JudcFAbS1srytG1QX1H XTsPkTDKHlwv2ZfmCSKK3sWHDrZfpRglxvcX2OwibcKVkKBJRRw36UuJOIj/u0WYABcYtusAb2+0 nqoGmOEYARnrseTZMIIG7jCCBdagAwIBAgIQcRVmBUrkkSFN6bxE+azT3DANBgkqhkiG9w0BAQUF ADCByjELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZv ciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQ cmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkw NDMwMjM1OTU5WjCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0 cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFs aWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBD QSAtIEczMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP 6bGNQU4099oL42r6ZYggCxET6ZvgSU6Lb9UB0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYH r54UGAdPWr2f0jGyVBlzRmoZQhHsEnMhjfXcMM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50 ABMN0Ibak2f4MwOuGjxraXj2wCyO4YM/d/mZ//6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yx BF6+wbaULZeQLSfSux7pg2qE9sSyriMGZSalJ1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ 6/tu1ULEvkHH9QIDAQABo4ICuTCCArUwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRw Oi8vb2NzcC52ZXJpc2lnbi5jb20wEgYDVR0TAQH/BAgwBgEB/wIBADBwBgNVHSAEaTBnMGUGC2CG SAGG+EUBBxcBMFYwKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9jcHMwKgYI KwYBBQUHAgIwHhocaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTA0BgNVHR8ELTArMCmgJ6Al hiNodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwbgYI KwYBBQUHAQwEYjBgoV6gXDBaMFgwVhYJaW1hZ2UvZ2lmMCEwHzAHBgUrDgMCGgQUS2u5KJYGDLvQ UjibKaxLB4shBRgwJhYkaHR0cDovL2xvZ28udmVyaXNpZ24uY29tL3ZzbG9nbzEuZ2lmMC4GA1Ud EQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRlTGFiZWw0LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EI Qf04BKJL57XM9UP2SSsR+DCB8QYDVR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4 BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkx RTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgLSBHM4IRAItbdVaEVIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZ gbWpBbVSOOk5hIls5DSoWufYbAlMJBq6WaSHO3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v 8dKBl8pUWkO/N4t6jhmND0OojPKvYLMVirOVnDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM6 1a4ScAjr+zvid+zoK2Q1ds262uDRyxTWcVibvtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/ XLJtSd5lUkL7DojS7Uodv0vj+Mxy+kgOZY5JyNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4 VRaMxmgD5yKocwuxvKDaUljdCg5/wYIxggS4MIIEtAIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTsw OQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykw OTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFz cyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczAhBcX1ns/Jl/DtI19/BXCcuBMAkGBSsO AwIaBQCgggMbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDUx NTE2MjUzOVowIwYJKoZIhvcNAQkEMRYEFGAWxcmzV4CqO0qJzgC2SoL9i1NoMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIIBAwYJKwYB BAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBo dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBW YWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVy IENBIC0gRzMCEFxfWez8mX8O0jX38FcJy4EwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkG A1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz dCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24u Y29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5W ZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczAhBcX1ns/Jl/DtI1 9/BXCcuBMA0GCSqGSIb3DQEBAQUABIGAkUBhwKM8R1OID+SPGAKFR35oZ8qWBvQe+4KdpVfQ40tK Tqcj2Eob3G0DQbZ4ZRylUD1GG5IBk94ja9vC5o7J5W2z06IiGHg0Z1JPIMlotDVcwg+R6LaGJAgr /sej7KX/COmFV0OVNGalm6/+O5/J8t2PPaxCRC+02tqNl2xPBQgAAAAAAAA= ------=_NextPart_000_0008_01CD3295.D6512350-- From mary.ietf.barnes@gmail.com Tue May 15 16:56:41 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87B1B11E80CB for ; Tue, 15 May 2012 16:56:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.634 X-Spam-Level: X-Spam-Status: No, score=-103.634 tagged_above=-999 required=5 tests=[AWL=-0.036, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vZHETTT69Jes for ; Tue, 15 May 2012 16:56:41 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id BDF8511E80B0 for ; Tue, 15 May 2012 16:56:40 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so186270vbb.31 for ; Tue, 15 May 2012 16:56:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=c3riUDXmE22IurDgfCddpLsKs+SSHfZGY8vN/PpO6B4=; b=wOe/qwcJ2hskqCj1jxjNQHEZnsFi40HLA1y94ElUPwE9hniv+gHeKw60gtxazqW3Q/ 2M8CM8ggvkoI7FbfHD366PngWNccLJfiDZ4BihgPwZ91+YXYhR3QeSNEf0J7hYuDzKJ2 w2lBzZ8VQ5UXrnIj9a+WT3tKXgRcBGLEZhQY4+r9CyH5ctXITnVge/URXgB6FkFMsjwH DbvxSR8QNnq8AuMy1mi8mH6p48GgpA/LPMJw+XmTGHlrid2pnG20vG6D+pg6B+OVU9aj /eZT7ueIBiQMTqS0n1Xd+dtOv56vZD8gpb8U2mf4M1jLtmrhCiJdhiSGfXQNJ2Rin6JM wLdQ== MIME-Version: 1.0 Received: by 10.220.210.20 with SMTP id gi20mr587622vcb.42.1337126200221; Tue, 15 May 2012 16:56:40 -0700 (PDT) Received: by 10.52.166.100 with HTTP; Tue, 15 May 2012 16:56:40 -0700 (PDT) Date: Tue, 15 May 2012 18:56:40 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=00221572766e2f1ebe04c01bf4e1 Subject: [clue] Deadline on 5/16 for Final IETF-83 minutes X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 15 May 2012 23:56:41 -0000 --00221572766e2f1ebe04c01bf4e1 Content-Type: text/plain; charset=ISO-8859-1 Hi all, Just a note that tomorrow 5/16 at 5pm PT is the cutoff for any changes to the minutes from IETF-83. If you have not reviewed them please do so now and let us know if you have any questions or concerns no later than noon Pacific on 5/16, so that we can resolve. http://www.ietf.org/proceedings/83/minutes/minutes-83-clue.txt Note that the minutes include a link to the meetecho recordings, which can be extremely helpful. Thanks, Mary. --00221572766e2f1ebe04c01bf4e1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all,

Just a note that tomorrow 5/16 at 5pm PT is the = cutoff for any changes to the minutes from IETF-83. =A0If you have not revi= ewed them please do so now and let us know if you have any questions or con= cerns no later than noon Pacific on 5/16, so that we can resolve.
http://www.ietf.org/proceedings/83/minutes/minutes-83-clue.txt

Note that the minutes include a link to the meetecho = recordings, which can be extremely helpful.

Thanks,
Mary.
--00221572766e2f1ebe04c01bf4e1-- From Mark.Duckworth@polycom.com Thu May 17 15:24:54 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AACF21F8773 for ; Thu, 17 May 2012 15:24:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.974 X-Spam-Level: X-Spam-Status: No, score=-5.974 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, J_CHICKENPOX_84=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JQJ1mH8NKWSe for ; Thu, 17 May 2012 15:24:53 -0700 (PDT) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 7CD9E21F8775 for ; Thu, 17 May 2012 15:24:53 -0700 (PDT) Received: from Crpmboxprd01.polycom.com ([fe80::ad68:5a0:c919:66b6]) by crpehubprd02.polycom.com ([fe80::5efe:10.236.0.154%12]) with mapi; Thu, 17 May 2012 15:24:53 -0700 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Thu, 17 May 2012 15:24:50 -0700 Thread-Topic: Framework example from RTP usage presentation in Paris Thread-Index: Ac00eHpBtBOO9d+xT1me22JTGNCAug== Message-ID: <44C6B6B2D0CF424AA90B6055548D7A6102FD83659C@CRPMBOXPRD01.polycom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [clue] Framework example from RTP usage presentation in Paris X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 17 May 2012 22:24:54 -0000 In the Paris meeting minutes there is an action item: - Framework: include examples/diagrams from chart 7&8 of RTP usage charts This is the text from the charts: Req. Media-4 - "It must be possible for an original source to move among sw= itched captures (i.e. at one time be sent for one switched capture, and at = a later time be sent for another one)." - The example is the three-camera-to-two-screen:=20 - Receiver, getting two switched captures (Left and Right). - Initially, source 1 is sent for the Left switched capture, source 2 for t= he Right switched capture. - After a change, source 2 is sent for the Left switched capture, source 3 = for the Right switched capture. - Notice that source 2 was Right, but is now Left. I'm trying to remember what the group thought should be added to the framew= ork. Is it something for the example section at the end? Here is a propos= al: The media provider makes an advertisement with five video captures and two = capture scene entries like this: VC1 - switched=3Dfalse, coords indicate it is on the left VC2 - switched=3Dfalse, coords indicate it is in the center VC3 - switched=3Dfalse, coords indicate it is on the right VC4 - switched=3Dtrue, coords indicate it is on the left VC5 - switched=3Dtrue, coords indicate it is on the right Capture scene entry 1 - (VC1, VC2, VC3) Capture scene entry 2 - (VC4, VC5) The media consumer chooses to receive VC4 and VC5. The provider initially sends original source VC1 media for VC4, and origina= l source VC2 media for VC5. Then after a switch, the provider sends original source VC2 media for VC4, = and original source VC3 media for VC5. So would it be helpful if I added this example into the framework? I think we talked about this issue also: >From the consumer's point of view, it is always receiving VC4 and VC5. The= consumer always needs to know, for every media packet it receives, which V= C (4 or 5) it belongs to. The consumer might also want to know that the vi= deo that was previously on VC5 was coming from the same camera that is now = sending video on VC4, but it doesn't need to know this instantly when the m= edia packets arrive. And during the switch, the consumer may need an I-fra= me for both VC4 and VC5. Should this issue also be described in the framework? Regards, Mark From Mark.Duckworth@polycom.com Fri May 18 09:56:36 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF74521F86F1 for ; Fri, 18 May 2012 09:56:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.279 X-Spam-Level: X-Spam-Status: No, score=-6.279 tagged_above=-999 required=5 tests=[AWL=0.320, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1RDWT4bv2DSu for ; Fri, 18 May 2012 09:56:36 -0700 (PDT) Received: from Crpehubprd01.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 1DF2021F863E for ; Fri, 18 May 2012 09:56:35 -0700 (PDT) Received: from Crpmboxprd01.polycom.com ([fe80::ad68:5a0:c919:66b6]) by Crpehubprd01.polycom.com ([fe80::5efe:10.236.0.158%14]) with mapi; Fri, 18 May 2012 09:56:35 -0700 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Fri, 18 May 2012 09:56:32 -0700 Thread-Topic: Ticket #8 - add description text to a capture scene Thread-Index: Ac01Fhkv9iYo2AjsQOaOdqQUOts2ww== Message-ID: <44C6B6B2D0CF424AA90B6055548D7A6102FD83676A@CRPMBOXPRD01.polycom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [clue] Ticket #8 - add description text to a capture scene X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 18 May 2012 16:56:36 -0000 Regarding Ticket #8 - How consumer differentiates between multiple capture = scenes. We discussed this a bit on the list, and on the April 10 phone meeting. I = think the group agreed we should add a human readable text string attribute= to a capture scene. Here is a proposal for adding text to the framework document section 6.2.1 = Capture scene attributes: Description attribute The description attribute is a human readable text string which describes t= he capture scene. A provider that advertises multiple capture scenes may u= se different descriptions to differentiate between them. Do we also want to add a similar description attribute to a media capture? Mark Duckworth From ron.even.tlv@gmail.com Fri May 18 13:00:45 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D008821F8582 for ; Fri, 18 May 2012 13:00:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.185 X-Spam-Level: X-Spam-Status: No, score=-1.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i0SzZtFOpUYN for ; Fri, 18 May 2012 13:00:45 -0700 (PDT) Received: from mail-wg0-f42.google.com (mail-wg0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id 0940921F8576 for ; Fri, 18 May 2012 13:00:41 -0700 (PDT) Received: by wgbds11 with SMTP id ds11so1147899wgb.1 for ; Fri, 18 May 2012 13:00:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language; bh=3v+KiN3NcIXZhvCjDE9qThy4gihy9Z6FiqYqovhkxiI=; b=O+UlxO3q+zkwu4B5UysRNAViTipdKwR7MWkM5Bc5fzlmuPfj1BDcVUw3tgLlVcx4Wl t/cRYXCdwJE70p8O2he4Dvh3QqgYkBfH4/y9EV5qohwZDYPNAQupuWJPuD+Vvq7u14Hf J1NQrNDMS2OC/M55CTt/ks1Lw/tbFXY0DCckBzmFoujO/w35nhhXhaRQj09INR6pW4LZ G99vsDnHyZ6pYQ/lk9G+WtEYfdTUUgBCvvac/a2UdAiFqoOFjxlPsJiLhVUbwH7aclTh 3Qv3Pnaz+eQdsGXDn2TlnIRVqvxAHBjKT0auFWwga6/tVJStn4oH0CEc5Ge7OWRUmBvE ejhQ== Received: by 10.180.107.101 with SMTP id hb5mr4600842wib.7.1337371241149; Fri, 18 May 2012 13:00:41 -0700 (PDT) Received: from windows8d787f9 (bzq-79-177-198-116.red.bezeqint.net. [79.177.198.116]) by mx.google.com with ESMTPS id g10sm3353329wiw.0.2012.05.18.13.00.38 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 18 May 2012 13:00:39 -0700 (PDT) From: "Roni Even" To: "'Duckworth, Mark'" , References: <44C6B6B2D0CF424AA90B6055548D7A6102FD83676A@CRPMBOXPRD01.polycom.com> In-Reply-To: <44C6B6B2D0CF424AA90B6055548D7A6102FD83676A@CRPMBOXPRD01.polycom.com> Date: Fri, 18 May 2012 22:58:10 +0300 Message-ID: <4fb6aa67.0a4cb40a.6f40.ffffb870@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: Ac01Fhkv9iYo2AjsQOaOdqQUOts2wwAGPc8w Content-Language: en-us Subject: Re: [clue] Ticket #8 - add description text to a capture scene X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 18 May 2012 20:00:45 -0000 Hi Mark, I am not sure about this agreement. My view is that we first need to understand what is meant by multiple capture scenes. For example is each identified by a separate co-ordinate space. When we have a room video and presentation is it two capture scene, if not then how do I provide the area of interest for the presentation if the video room is in real co-ordinate (mm). If they are not the same we need to have a purpose value for the capture scene which is machine readable. I do not object having a human readable description but it is not enough and it does not provide a way to differentiate between them. What you can say is that a machine readable description can be used by a user (!!!!) to select a capture scene if the information is rendered on a monitor allowing hime to select as part of a menu system. As for having user readable information for media capture it can be as useful as the capture scene description. I think that an important description is the whole system description ( e.g. Mark's home TP system) Roni Even > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Duckworth, Mark > Sent: Friday, May 18, 2012 7:57 PM > To: clue@ietf.org > Subject: [clue] Ticket #8 - add description text to a capture scene > > Regarding Ticket #8 - How consumer differentiates between multiple > capture scenes. > We discussed this a bit on the list, and on the April 10 phone meeting. > I think the group agreed we should add a human readable text string > attribute to a capture scene. > > Here is a proposal for adding text to the framework document section > 6.2.1 Capture scene attributes: > > Description attribute > > The description attribute is a human readable text string which > describes the capture scene. A provider that advertises multiple > capture scenes may use different descriptions to differentiate between > them. > > > Do we also want to add a similar description attribute to a media > capture? > > Mark Duckworth > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From Mark.Duckworth@polycom.com Fri May 18 13:46:53 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16FC621F85F8 for ; Fri, 18 May 2012 13:46:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X1ZgntDNJVky for ; Fri, 18 May 2012 13:46:52 -0700 (PDT) Received: from Crpehubprd01.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 8753821F85F1 for ; Fri, 18 May 2012 13:46:52 -0700 (PDT) Received: from Crpmboxprd01.polycom.com ([fe80::ad68:5a0:c919:66b6]) by Crpehubprd01.polycom.com ([fe80::5efe:10.236.0.158%14]) with mapi; Fri, 18 May 2012 13:46:51 -0700 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Fri, 18 May 2012 13:46:50 -0700 Thread-Topic: [clue] Ticket #8 - add description text to a capture scene Thread-Index: Ac01Fhkv9iYo2AjsQOaOdqQUOts2wwAGPc8wAAF/vDA= Message-ID: <44C6B6B2D0CF424AA90B6055548D7A6102FD836877@CRPMBOXPRD01.polycom.com> References: <44C6B6B2D0CF424AA90B6055548D7A6102FD83676A@CRPMBOXPRD01.polycom.com> <4fb6aa67.0a4cb40a.6f40.ffffb870@mx.google.com> In-Reply-To: <4fb6aa67.0a4cb40a.6f40.ffffb870@mx.google.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [clue] Ticket #8 - add description text to a capture scene X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 18 May 2012 20:46:53 -0000 Hi Roni, Thanks for the comments. I didn't mean to say this proposed description attribute is enough to resol= ve Ticket #8, only that I thought the group agreed we should add the attrib= ute to the framework, related to this ticket. Yes each capture scene is identified by a different coordinate space. From= the framework: "A provider can express spatial relationships between media captures that are included in the same capture scene. But there is no spatial relationship between media captures that are in different capture scene= s." I think the typical case is for room video and presentation video to be in = separate capture scenes. From the framework: "A media provider might typically use one capture scene for main participant media and another capture scene for a computer generated presentation." I remember people saying it would not be a good idea to prohibit putting a = room video capture and a presentation capture into the same capture scene, = but I don't know of a case when that would be desired. You suggest maybe h= aving a purpose attribute for the capture scene. If we do that, does that = mean every media capture in that scene has that same purpose? That is oka= y with me, but I thought others might object. For the whole system description, I thought there is already a standard way= to provide "caller ID" information that serves that purpose. Is that true= ? Regards, Mark > -----Original Message----- > From: Roni Even [mailto:ron.even.tlv@gmail.com] > Sent: Friday, May 18, 2012 3:58 PM > To: Duckworth, Mark; clue@ietf.org > Subject: RE: [clue] Ticket #8 - add description text to a capture scene >=20 > Hi Mark, > I am not sure about this agreement. My view is that we first need to > understand what is meant by multiple capture scenes. For example is each > identified by a separate co-ordinate space. > When we have a room video and presentation is it two capture scene, if no= t > then how do I provide the area of interest for the presentation if the vi= deo > room is in real co-ordinate (mm). > If they are not the same we need to have a purpose value for the capture > scene which is machine readable. >=20 > I do not object having a human readable description but it is not enough = and > it does not provide a way to differentiate between them. > What you can say is that a machine readable description can be used by a > user (!!!!) to select a capture scene if the information is rendered on a > monitor allowing hime to select as part of a menu system. >=20 > As for having user readable information for media capture it can be as us= eful > as the capture scene description. I think that an important description i= s the > whole system description ( e.g. Mark's home TP system) >=20 > Roni Even >=20 >=20 > > -----Original Message----- > > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf > > Of Duckworth, Mark > > Sent: Friday, May 18, 2012 7:57 PM > > To: clue@ietf.org > > Subject: [clue] Ticket #8 - add description text to a capture scene > > > > Regarding Ticket #8 - How consumer differentiates between multiple > > capture scenes. > > We discussed this a bit on the list, and on the April 10 phone meeting. > > I think the group agreed we should add a human readable text string > > attribute to a capture scene. > > > > Here is a proposal for adding text to the framework document section > > 6.2.1 Capture scene attributes: > > > > Description attribute > > > > The description attribute is a human readable text string which > > describes the capture scene. A provider that advertises multiple > > capture scenes may use different descriptions to differentiate between > > them. > > > > > > Do we also want to add a similar description attribute to a media > > capture? > > > > Mark Duckworth > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue From ron.even.tlv@gmail.com Fri May 18 14:10:37 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D29E21F859E for ; Fri, 18 May 2012 14:10:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.392 X-Spam-Level: X-Spam-Status: No, score=-2.392 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mo++YaCS+rfj for ; Fri, 18 May 2012 14:10:36 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 039D321F8592 for ; Fri, 18 May 2012 14:10:35 -0700 (PDT) Received: by werb13 with SMTP id b13so898668wer.31 for ; Fri, 18 May 2012 14:10:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language; bh=49UltM58T1hYvWW5c+U7Xp2vc0WMiJXZqzkY7JOMnmE=; b=ISjMcR20o4ikcbVi2HOOHTrJQWVooPDUjrqHuvLI5QF3Pnp+ANRonRl1BrTEQGWSOl je7kga94QDyN2Xqa9RbNp6sUoP96+RaEvDgn3uPQvTRRJ84f/cBBWpUCq3rQYfD4q1VC HMqvIHOLx+0PvRdyLR019fcLexxQr5OK4WV+omO7QDlexKRUwMLhzRLI4j4tR2oxf9MA /ROs1Bxmlmv+FDE9iNjTaqBp4/DtcCJYrmTtSmaqJ0p3nGxoaVV4039OEh1JfkSI0b6E +07wuOYeHJBuQHa1ZXz+bJMXRIaTNZlFCjk+tkl4u/YUtYhTVEyMPawCeoVzAmFCGGqw lX3g== Received: by 10.180.87.35 with SMTP id u3mr4942092wiz.11.1337375435012; Fri, 18 May 2012 14:10:35 -0700 (PDT) Received: from windows8d787f9 (bzq-79-177-198-116.red.bezeqint.net. [79.177.198.116]) by mx.google.com with ESMTPS id gv4sm5772987wib.8.2012.05.18.14.10.33 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 18 May 2012 14:10:34 -0700 (PDT) From: "Roni Even" To: "'Duckworth, Mark'" , References: <44C6B6B2D0CF424AA90B6055548D7A6102FD83676A@CRPMBOXPRD01.polycom.com> <4fb6aa67.0a4cb40a.6f40.ffffb870@mx.google.com> <44C6B6B2D0CF424AA90B6055548D7A6102FD836877@CRPMBOXPRD01.polycom.com> In-Reply-To: <44C6B6B2D0CF424AA90B6055548D7A6102FD836877@CRPMBOXPRD01.polycom.com> Date: Sat, 19 May 2012 00:08:04 +0300 Message-ID: <4fb6baca.a46ab40a.1103.ffffc656@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: Ac01Fhkv9iYo2AjsQOaOdqQUOts2wwAGPc8wAAF/vDAAASppgA== Content-Language: en-us Subject: Re: [clue] Ticket #8 - add description text to a capture scene X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 18 May 2012 21:10:37 -0000 Hi Mark, I think that this goes back to the question of how we define a capture scene. Just saying that each has a unique co-ordinate system is not enough unless we are saying that all media captures inside a capture scene MUST provide spatial information using the same co-ordinate systems and units. This means that the units can be part of the capture scene. It will also mean that room video and presentation are different capture scenes. I think that such definition will be in-line with the name "scene" Roni > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Duckworth, Mark > Sent: Friday, May 18, 2012 11:47 PM > To: clue@ietf.org > Subject: Re: [clue] Ticket #8 - add description text to a capture scene > > Hi Roni, > > Thanks for the comments. > I didn't mean to say this proposed description attribute is enough to > resolve Ticket #8, only that I thought the group agreed we should add > the attribute to the framework, related to this ticket. > > Yes each capture scene is identified by a different coordinate space. > From the framework: > "A provider can express spatial relationships between media > captures > that are included in the same capture scene. But there is no > spatial > relationship between media captures that are in different capture > scenes." > > I think the typical case is for room video and presentation video to be > in separate capture scenes. From the framework: > "A media provider might typically use one capture > scene for main participant media and another capture scene for a > computer generated presentation." > > I remember people saying it would not be a good idea to prohibit > putting a room video capture and a presentation capture into the same > capture scene, but I don't know of a case when that would be desired. > You suggest maybe having a purpose attribute for the capture scene. If > we do that, does that mean every media capture in that scene has that > same purpose? That is okay with me, but I thought others might > object. > > For the whole system description, I thought there is already a standard > way to provide "caller ID" information that serves that purpose. Is > that true? > > Regards, > Mark > > > -----Original Message----- > > From: Roni Even [mailto:ron.even.tlv@gmail.com] > > Sent: Friday, May 18, 2012 3:58 PM > > To: Duckworth, Mark; clue@ietf.org > > Subject: RE: [clue] Ticket #8 - add description text to a capture > > scene > > > > Hi Mark, > > I am not sure about this agreement. My view is that we first need to > > understand what is meant by multiple capture scenes. For example is > > each identified by a separate co-ordinate space. > > When we have a room video and presentation is it two capture scene, > if > > not then how do I provide the area of interest for the presentation > if > > the video room is in real co-ordinate (mm). > > If they are not the same we need to have a purpose value for the > > capture scene which is machine readable. > > > > I do not object having a human readable description but it is not > > enough and it does not provide a way to differentiate between them. > > What you can say is that a machine readable description can be used > by > > a user (!!!!) to select a capture scene if the information is > rendered > > on a monitor allowing hime to select as part of a menu system. > > > > As for having user readable information for media capture it can be > as > > useful as the capture scene description. I think that an important > > description is the whole system description ( e.g. Mark's home TP > > system) > > > > Roni Even > > > > > > > -----Original Message----- > > > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On > Behalf > > > Of Duckworth, Mark > > > Sent: Friday, May 18, 2012 7:57 PM > > > To: clue@ietf.org > > > Subject: [clue] Ticket #8 - add description text to a capture scene > > > > > > Regarding Ticket #8 - How consumer differentiates between multiple > > > capture scenes. > > > We discussed this a bit on the list, and on the April 10 phone > meeting. > > > I think the group agreed we should add a human readable text string > > > attribute to a capture scene. > > > > > > Here is a proposal for adding text to the framework document > section > > > 6.2.1 Capture scene attributes: > > > > > > Description attribute > > > > > > The description attribute is a human readable text string which > > > describes the capture scene. A provider that advertises multiple > > > capture scenes may use different descriptions to differentiate > > > between them. > > > > > > > > > Do we also want to add a similar description attribute to a media > > > capture? > > > > > > Mark Duckworth > > > _______________________________________________ > > > 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 From Mark.Duckworth@polycom.com Fri May 18 14:32:24 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4802021F85F2 for ; Fri, 18 May 2012 14:32:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q8P5wVCi5QuS for ; Fri, 18 May 2012 14:32:23 -0700 (PDT) Received: from Crpehubprd01.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id F098B21F85CD for ; Fri, 18 May 2012 14:32:20 -0700 (PDT) Received: from Crpmboxprd01.polycom.com ([fe80::ad68:5a0:c919:66b6]) by Crpehubprd01.polycom.com ([fe80::5efe:10.236.0.158%14]) with mapi; Fri, 18 May 2012 14:32:20 -0700 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Fri, 18 May 2012 14:32:17 -0700 Thread-Topic: [clue] Ticket #8 - capture scene coordinates and content attribute Thread-Index: Ac01Pao93L1Yb+fHS0y4MTnwKKCUkQ== Message-ID: <44C6B6B2D0CF424AA90B6055548D7A6102FD8368AF@CRPMBOXPRD01.polycom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [clue] Ticket #8 - capture scene coordinates and content attribute X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 18 May 2012 21:32:24 -0000 Hi Roni, I changed the subject line to match the discussion. The units are already part of the capture scene. See the framework section= "6.2.1 Capture scene attributes", the "Scale attribute". The framework already says all media captures inside a capture scene, that = provide spatial information, use the same coordinate system and units. How= ever, it is not mandatory for every media capture to provide spatial inform= ation (values for area of capture and point of capture attributes). So you= are proposing we make it mandatory, that if any media capture in a capture= scene provides an area of capture attribute, then all media captures in th= at scene must also provide an area of capture attribute, is that correct? And are you also proposing that all media captures within a capture scene m= ust have the same value for the content attribute? Mark > -----Original Message----- > From: Roni Even [mailto:ron.even.tlv@gmail.com] > Sent: Friday, May 18, 2012 5:08 PM > To: Duckworth, Mark; clue@ietf.org > Subject: RE: [clue] Ticket #8 - add description text to a capture scene >=20 > Hi Mark, > I think that this goes back to the question of how we define a capture sc= ene. > Just saying that each has a unique co-ordinate system is not enough unle= ss > we are saying that all media captures inside a capture scene MUST provide > spatial information using the same co-ordinate systems and units. > This means that the units can be part of the capture scene. It will also = mean > that room video and presentation are different capture scenes. I think th= at > such definition will be in-line with the name "scene" >=20 > Roni >=20 > > -----Original Message----- > > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf > > Of Duckworth, Mark > > Sent: Friday, May 18, 2012 11:47 PM > > To: clue@ietf.org > > Subject: Re: [clue] Ticket #8 - add description text to a capture > > scene > > > > Hi Roni, > > > > Thanks for the comments. > > I didn't mean to say this proposed description attribute is enough to > > resolve Ticket #8, only that I thought the group agreed we should add > > the attribute to the framework, related to this ticket. > > > > Yes each capture scene is identified by a different coordinate space. > > From the framework: > > "A provider can express spatial relationships between media > > captures > > that are included in the same capture scene. But there is no > > spatial > > relationship between media captures that are in different capture > > scenes." > > > > I think the typical case is for room video and presentation video to > > be in separate capture scenes. From the framework: > > "A media provider might typically use one capture > > scene for main participant media and another capture scene for a > > computer generated presentation." > > > > I remember people saying it would not be a good idea to prohibit > > putting a room video capture and a presentation capture into the same > > capture scene, but I don't know of a case when that would be desired. > > You suggest maybe having a purpose attribute for the capture scene. > > If we do that, does that mean every media capture in that scene has tha= t > > same purpose? That is okay with me, but I thought others might > > object. > > > > For the whole system description, I thought there is already a > > standard way to provide "caller ID" information that serves that > > purpose. Is that true? > > > > Regards, > > Mark > > > > > -----Original Message----- > > > From: Roni Even [mailto:ron.even.tlv@gmail.com] > > > Sent: Friday, May 18, 2012 3:58 PM > > > To: Duckworth, Mark; clue@ietf.org > > > Subject: RE: [clue] Ticket #8 - add description text to a capture > > > scene > > > > > > Hi Mark, > > > I am not sure about this agreement. My view is that we first need to > > > understand what is meant by multiple capture scenes. For example is > > > each identified by a separate co-ordinate space. > > > When we have a room video and presentation is it two capture scene, > > if > > > not then how do I provide the area of interest for the presentation > > if > > > the video room is in real co-ordinate (mm). > > > If they are not the same we need to have a purpose value for the > > > capture scene which is machine readable. > > > > > > I do not object having a human readable description but it is not > > > enough and it does not provide a way to differentiate between them. > > > What you can say is that a machine readable description can be used > > by > > > a user (!!!!) to select a capture scene if the information is > > rendered > > > on a monitor allowing hime to select as part of a menu system. > > > > > > As for having user readable information for media capture it can be > > as > > > useful as the capture scene description. I think that an important > > > description is the whole system description ( e.g. Mark's home TP > > > system) > > > > > > Roni Even > > > > > > > > > > -----Original Message----- > > > > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On > > Behalf > > > > Of Duckworth, Mark > > > > Sent: Friday, May 18, 2012 7:57 PM > > > > To: clue@ietf.org > > > > Subject: [clue] Ticket #8 - add description text to a capture > > > > scene > > > > > > > > Regarding Ticket #8 - How consumer differentiates between multiple > > > > capture scenes. > > > > We discussed this a bit on the list, and on the April 10 phone > > meeting. > > > > I think the group agreed we should add a human readable text > > > > string attribute to a capture scene. > > > > > > > > Here is a proposal for adding text to the framework document > > section > > > > 6.2.1 Capture scene attributes: > > > > > > > > Description attribute > > > > > > > > The description attribute is a human readable text string which > > > > describes the capture scene. A provider that advertises multiple > > > > capture scenes may use different descriptions to differentiate > > > > between them. > > > > > > > > > > > > Do we also want to add a similar description attribute to a media > > > > capture? > > > > > > > > Mark Duckworth > > > > _______________________________________________ > > > > 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 From pkyzivat@alum.mit.edu Fri May 18 14:33:20 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48BE021F85CD for ; Fri, 18 May 2012 14:33:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F6eOl0hVpmNt for ; Fri, 18 May 2012 14:33:19 -0700 (PDT) Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [76.96.59.212]) by ietfa.amsl.com (Postfix) with ESMTP id 531AF21F85F2 for ; Fri, 18 May 2012 14:33:19 -0700 (PDT) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta14.westchester.pa.mail.comcast.net with comcast id BYoT1j0051c6gX85EZZJBE; Fri, 18 May 2012 21:33:18 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta23.westchester.pa.mail.comcast.net with comcast id BZZJ1j00A07duvL3jZZJuJ; Fri, 18 May 2012 21:33:18 +0000 Message-ID: <4FB6C01D.9030004@alum.mit.edu> Date: Fri, 18 May 2012 17:33:17 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: clue@ietf.org References: <44C6B6B2D0CF424AA90B6055548D7A6102FD83676A@CRPMBOXPRD01.polycom.com> <4fb6aa67.0a4cb40a.6f40.ffffb870@mx.google.com> <44C6B6B2D0CF424AA90B6055548D7A6102FD836877@CRPMBOXPRD01.polycom.com> <4fb6baca.a46ab40a.1103.ffffc656@mx.google.com> In-Reply-To: <4fb6baca.a46ab40a.1103.ffffc656@mx.google.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] Ticket #8 - add description text to a capture scene X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 18 May 2012 21:33:20 -0000 On 5/18/12 5:08 PM, Roni Even wrote: > Hi Mark, > I think that this goes back to the question of how we define a capture > scene. Just saying that each has a unique co-ordinate system is not enough > unless we are saying that all media captures inside a capture scene MUST > provide spatial information using the same co-ordinate systems and units. AFAIK we did decide this. Isn't that why it was decided that that the scale attribute is associated with the capture scene and not with the individual capture sets? > This means that the units can be part of the capture scene. They are, in 6.2.1 of the framework, not in 6.1.1. > It will also > mean that room video and presentation are different capture scenes. I think > that such definition will be in-line with the name "scene" In some cases it may make sense for the presentation to be in the same scene as the room video, but there are also cases where having them separate makes sense. Unless we find some compelling reason to nail it down one way or another. (E.g. If the presentation is being shown on a screen in the room, and the presenter is pointing to that screen, then it may make sense to have the presenter in one capture, the presentation in another, with both in the same scene, so there is enough info to display them both in a way that the pointing makes sense.) Thanks, Paul > Roni > >> -----Original Message----- >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of >> Duckworth, Mark >> Sent: Friday, May 18, 2012 11:47 PM >> To: clue@ietf.org >> Subject: Re: [clue] Ticket #8 - add description text to a capture scene >> >> Hi Roni, >> >> Thanks for the comments. >> I didn't mean to say this proposed description attribute is enough to >> resolve Ticket #8, only that I thought the group agreed we should add >> the attribute to the framework, related to this ticket. >> >> Yes each capture scene is identified by a different coordinate space. >> From the framework: >> "A provider can express spatial relationships between media >> captures >> that are included in the same capture scene. But there is no >> spatial >> relationship between media captures that are in different capture >> scenes." >> >> I think the typical case is for room video and presentation video to be >> in separate capture scenes. From the framework: >> "A media provider might typically use one capture >> scene for main participant media and another capture scene for a >> computer generated presentation." >> >> I remember people saying it would not be a good idea to prohibit >> putting a room video capture and a presentation capture into the same >> capture scene, but I don't know of a case when that would be desired. >> You suggest maybe having a purpose attribute for the capture scene. If >> we do that, does that mean every media capture in that scene has that >> same purpose? That is okay with me, but I thought others might >> object. >> >> For the whole system description, I thought there is already a standard >> way to provide "caller ID" information that serves that purpose. Is >> that true? >> >> Regards, >> Mark >> >>> -----Original Message----- >>> From: Roni Even [mailto:ron.even.tlv@gmail.com] >>> Sent: Friday, May 18, 2012 3:58 PM >>> To: Duckworth, Mark; clue@ietf.org >>> Subject: RE: [clue] Ticket #8 - add description text to a capture >>> scene >>> >>> Hi Mark, >>> I am not sure about this agreement. My view is that we first need to >>> understand what is meant by multiple capture scenes. For example is >>> each identified by a separate co-ordinate space. >>> When we have a room video and presentation is it two capture scene, >> if >>> not then how do I provide the area of interest for the presentation >> if >>> the video room is in real co-ordinate (mm). >>> If they are not the same we need to have a purpose value for the >>> capture scene which is machine readable. >>> >>> I do not object having a human readable description but it is not >>> enough and it does not provide a way to differentiate between them. >>> What you can say is that a machine readable description can be used >> by >>> a user (!!!!) to select a capture scene if the information is >> rendered >>> on a monitor allowing hime to select as part of a menu system. >>> >>> As for having user readable information for media capture it can be >> as >>> useful as the capture scene description. I think that an important >>> description is the whole system description ( e.g. Mark's home TP >>> system) >>> >>> Roni Even >>> >>> >>>> -----Original Message----- >>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On >> Behalf >>>> Of Duckworth, Mark >>>> Sent: Friday, May 18, 2012 7:57 PM >>>> To: clue@ietf.org >>>> Subject: [clue] Ticket #8 - add description text to a capture scene >>>> >>>> Regarding Ticket #8 - How consumer differentiates between multiple >>>> capture scenes. >>>> We discussed this a bit on the list, and on the April 10 phone >> meeting. >>>> I think the group agreed we should add a human readable text string >>>> attribute to a capture scene. >>>> >>>> Here is a proposal for adding text to the framework document >> section >>>> 6.2.1 Capture scene attributes: >>>> >>>> Description attribute >>>> >>>> The description attribute is a human readable text string which >>>> describes the capture scene. A provider that advertises multiple >>>> capture scenes may use different descriptions to differentiate >>>> between them. >>>> >>>> >>>> Do we also want to add a similar description attribute to a media >>>> capture? >>>> >>>> Mark Duckworth >>>> _______________________________________________ >>>> clue mailing list >>>> clue@ietf.org >>>> https://www.ietf.org/mailman/listinfo/clue >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From pkyzivat@alum.mit.edu Fri May 18 14:39:43 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3097621F8609 for ; Fri, 18 May 2012 14:39:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j0OGmbP1l8QL for ; Fri, 18 May 2012 14:39:42 -0700 (PDT) Received: from qmta01.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [76.96.62.24]) by ietfa.amsl.com (Postfix) with ESMTP id 5692021F8602 for ; Fri, 18 May 2012 14:39:42 -0700 (PDT) Received: from omta14.westchester.pa.mail.comcast.net ([76.96.62.60]) by qmta01.westchester.pa.mail.comcast.net with comcast id BZRi1j0011HzFnQ51Zfh5A; Fri, 18 May 2012 21:39:41 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta14.westchester.pa.mail.comcast.net with comcast id BZfh1j00J07duvL3aZfhDE; Fri, 18 May 2012 21:39:41 +0000 Message-ID: <4FB6C19C.9030300@alum.mit.edu> Date: Fri, 18 May 2012 17:39:40 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: clue@ietf.org References: <44C6B6B2D0CF424AA90B6055548D7A6102FD83676A@CRPMBOXPRD01.polycom.com> <4fb6aa67.0a4cb40a.6f40.ffffb870@mx.google.com> <44C6B6B2D0CF424AA90B6055548D7A6102FD836877@CRPMBOXPRD01.polycom.com> In-Reply-To: <44C6B6B2D0CF424AA90B6055548D7A6102FD836877@CRPMBOXPRD01.polycom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] Ticket #8 - add description text to a capture scene X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 18 May 2012 21:39:43 -0000 On 5/18/12 4:46 PM, Duckworth, Mark wrote: > Hi Roni, > > Thanks for the comments. > I didn't mean to say this proposed description attribute is enough to resolve Ticket #8, only that I thought the group agreed we should add the attribute to the framework, related to this ticket. I agree with this - its part of a resolution to #8. > Yes each capture scene is identified by a different coordinate space. From the framework: > "A provider can express spatial relationships between media captures > that are included in the same capture scene. But there is no spatial > relationship between media captures that are in different capture scenes." > > I think the typical case is for room video and presentation video to be in separate capture scenes. From the framework: > "A media provider might typically use one capture > scene for main participant media and another capture scene for a > computer generated presentation." > > I remember people saying it would not be a good idea to prohibit putting a room video capture and a presentation capture into the same capture scene, but I don't know of a case when that would be desired. I just posted another reply that gave one possible reason. > You suggest maybe having a purpose attribute for the capture scene. If we do that, does that mean every media capture in that scene has that same purpose? That is okay with me, but I thought others might object. I think this might be helpful, but needs more consideration of exactly what it would mean, what the possible values might be, etc. Thanks, Paul > For the whole system description, I thought there is already a standard way to provide "caller ID" information that serves that purpose. Is that true? > > Regards, > Mark > >> -----Original Message----- >> From: Roni Even [mailto:ron.even.tlv@gmail.com] >> Sent: Friday, May 18, 2012 3:58 PM >> To: Duckworth, Mark; clue@ietf.org >> Subject: RE: [clue] Ticket #8 - add description text to a capture scene >> >> Hi Mark, >> I am not sure about this agreement. My view is that we first need to >> understand what is meant by multiple capture scenes. For example is each >> identified by a separate co-ordinate space. >> When we have a room video and presentation is it two capture scene, if not >> then how do I provide the area of interest for the presentation if the video >> room is in real co-ordinate (mm). >> If they are not the same we need to have a purpose value for the capture >> scene which is machine readable. >> >> I do not object having a human readable description but it is not enough and >> it does not provide a way to differentiate between them. >> What you can say is that a machine readable description can be used by a >> user (!!!!) to select a capture scene if the information is rendered on a >> monitor allowing hime to select as part of a menu system. >> >> As for having user readable information for media capture it can be as useful >> as the capture scene description. I think that an important description is the >> whole system description ( e.g. Mark's home TP system) >> >> Roni Even >> >> >>> -----Original Message----- >>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf >>> Of Duckworth, Mark >>> Sent: Friday, May 18, 2012 7:57 PM >>> To: clue@ietf.org >>> Subject: [clue] Ticket #8 - add description text to a capture scene >>> >>> Regarding Ticket #8 - How consumer differentiates between multiple >>> capture scenes. >>> We discussed this a bit on the list, and on the April 10 phone meeting. >>> I think the group agreed we should add a human readable text string >>> attribute to a capture scene. >>> >>> Here is a proposal for adding text to the framework document section >>> 6.2.1 Capture scene attributes: >>> >>> Description attribute >>> >>> The description attribute is a human readable text string which >>> describes the capture scene. A provider that advertises multiple >>> capture scenes may use different descriptions to differentiate between >>> them. >>> >>> >>> Do we also want to add a similar description attribute to a media >>> capture? >>> >>> Mark Duckworth >>> _______________________________________________ >>> 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 > From ron.even.tlv@gmail.com Fri May 18 21:12:23 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4377511E8072 for ; Fri, 18 May 2012 21:12:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.995 X-Spam-Level: X-Spam-Status: No, score=-2.995 tagged_above=-999 required=5 tests=[AWL=0.604, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tktzeg-95bke for ; Fri, 18 May 2012 21:12:22 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id E44879E802E for ; Fri, 18 May 2012 21:12:21 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so2329317wgb.13 for ; Fri, 18 May 2012 21:12:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language; bh=arAC+ATYNepjofsdoudhULqtbnrdfkZnjXAb52bjrE4=; b=zAEwL+5M4zTcP7Od/VTvyIIXPk4pKl8E9hme0lM+BW2n0GzYr/xI38cqGbN74g2nPh EAqdhK/x5aJNUPaINOwFOBcj3xVNbIRN6fDQxZktxq+OSz5gyjbaGEFUbAsLvv8AaWUN /mCPw/uf7CQrW/91ZR+NjcRIdBVS1mqNYlLc9zWtrRv26WKrBBUzp0EopqcfRTMuFqa+ aeSTPWiIxU+ivwe5i5juLziMHSWQoiEDf5w/5W9sCH+T+p2/nmMGG8x/953i4KrY9RsZ /5rLp9UuaEFUwoKTZWroc1xRxTMYQ1JIFQAiCON0BY/PM9SuSm3NTKPIN43H9ChS53Pe gHoA== Received: by 10.180.103.202 with SMTP id fy10mr7218233wib.17.1337400740946; Fri, 18 May 2012 21:12:20 -0700 (PDT) Received: from windows8d787f9 (bzq-79-177-198-116.red.bezeqint.net. [79.177.198.116]) by mx.google.com with ESMTPS id fo7sm5933984wib.9.2012.05.18.21.12.17 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 18 May 2012 21:12:19 -0700 (PDT) From: "Roni Even" To: "'Duckworth, Mark'" , References: <44C6B6B2D0CF424AA90B6055548D7A6102FD8368AF@CRPMBOXPRD01.polycom.com> In-Reply-To: <44C6B6B2D0CF424AA90B6055548D7A6102FD8368AF@CRPMBOXPRD01.polycom.com> Date: Sat, 19 May 2012 07:09:48 +0300 Message-ID: <4fb71da3.8766b40a.2cb4.1486@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: Ac01Pao93L1Yb+fHS0y4MTnwKKCUkQANyoSg Content-Language: en-us Subject: Re: [clue] Ticket #8 - capture scene coordinates and content attribute X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 19 May 2012 04:12:23 -0000 Mark, What I am saying that we need to clarify what is a capture scene, I think that if we say that all media captures in a scene must provide the area of capture information with the same units then it becomes clear that it reflects a set that can be rendered together. Roni > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Duckworth, Mark > Sent: Saturday, May 19, 2012 12:32 AM > To: clue@ietf.org > Subject: Re: [clue] Ticket #8 - capture scene coordinates and content > attribute > > Hi Roni, > I changed the subject line to match the discussion. > > The units are already part of the capture scene. See the framework > section "6.2.1 Capture scene attributes", the "Scale attribute". > > The framework already says all media captures inside a capture scene, > that provide spatial information, use the same coordinate system and > units. However, it is not mandatory for every media capture to provide > spatial information (values for area of capture and point of capture > attributes). So you are proposing we make it mandatory, that if any > media capture in a capture scene provides an area of capture attribute, > then all media captures in that scene must also provide an area of > capture attribute, is that correct? > > And are you also proposing that all media captures within a capture > scene must have the same value for the content attribute? > > Mark > > > -----Original Message----- > > From: Roni Even [mailto:ron.even.tlv@gmail.com] > > Sent: Friday, May 18, 2012 5:08 PM > > To: Duckworth, Mark; clue@ietf.org > > Subject: RE: [clue] Ticket #8 - add description text to a capture > > scene > > > > Hi Mark, > > I think that this goes back to the question of how we define a > capture scene. > > Just saying that each has a unique co-ordinate system is not enough > > unless we are saying that all media captures inside a capture scene > > MUST provide spatial information using the same co-ordinate systems > and units. > > This means that the units can be part of the capture scene. It will > > also mean that room video and presentation are different capture > > scenes. I think that such definition will be in-line with the name > "scene" > > > > Roni > > > > > -----Original Message----- > > > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On > Behalf > > > Of Duckworth, Mark > > > Sent: Friday, May 18, 2012 11:47 PM > > > To: clue@ietf.org > > > Subject: Re: [clue] Ticket #8 - add description text to a capture > > > scene > > > > > > Hi Roni, > > > > > > Thanks for the comments. > > > I didn't mean to say this proposed description attribute is enough > > > to resolve Ticket #8, only that I thought the group agreed we > should > > > add the attribute to the framework, related to this ticket. > > > > > > Yes each capture scene is identified by a different coordinate > space. > > > From the framework: > > > "A provider can express spatial relationships between media > > > captures > > > that are included in the same capture scene. But there is no > > > spatial > > > relationship between media captures that are in different > > > capture scenes." > > > > > > I think the typical case is for room video and presentation video > to > > > be in separate capture scenes. From the framework: > > > "A media provider might typically use one capture > > > scene for main participant media and another capture scene for > a > > > computer generated presentation." > > > > > > I remember people saying it would not be a good idea to prohibit > > > putting a room video capture and a presentation capture into the > > > same capture scene, but I don't know of a case when that would be > desired. > > > You suggest maybe having a purpose attribute for the capture scene. > > > If we do that, does that mean every media capture in that scene has > that > > > same purpose? That is okay with me, but I thought others might > > > object. > > > > > > For the whole system description, I thought there is already a > > > standard way to provide "caller ID" information that serves that > > > purpose. Is that true? > > > > > > Regards, > > > Mark > > > > > > > -----Original Message----- > > > > From: Roni Even [mailto:ron.even.tlv@gmail.com] > > > > Sent: Friday, May 18, 2012 3:58 PM > > > > To: Duckworth, Mark; clue@ietf.org > > > > Subject: RE: [clue] Ticket #8 - add description text to a capture > > > > scene > > > > > > > > Hi Mark, > > > > I am not sure about this agreement. My view is that we first need > > > > to understand what is meant by multiple capture scenes. For > > > > example is each identified by a separate co-ordinate space. > > > > When we have a room video and presentation is it two capture > > > > scene, > > > if > > > > not then how do I provide the area of interest for the > > > > presentation > > > if > > > > the video room is in real co-ordinate (mm). > > > > If they are not the same we need to have a purpose value for the > > > > capture scene which is machine readable. > > > > > > > > I do not object having a human readable description but it is not > > > > enough and it does not provide a way to differentiate between > them. > > > > What you can say is that a machine readable description can be > > > > used > > > by > > > > a user (!!!!) to select a capture scene if the information is > > > rendered > > > > on a monitor allowing hime to select as part of a menu system. > > > > > > > > As for having user readable information for media capture it can > > > > be > > > as > > > > useful as the capture scene description. I think that an > important > > > > description is the whole system description ( e.g. Mark's home TP > > > > system) > > > > > > > > Roni Even > > > > > > > > > > > > > -----Original Message----- > > > > > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On > > > Behalf > > > > > Of Duckworth, Mark > > > > > Sent: Friday, May 18, 2012 7:57 PM > > > > > To: clue@ietf.org > > > > > Subject: [clue] Ticket #8 - add description text to a capture > > > > > scene > > > > > > > > > > Regarding Ticket #8 - How consumer differentiates between > > > > > multiple capture scenes. > > > > > We discussed this a bit on the list, and on the April 10 phone > > > meeting. > > > > > I think the group agreed we should add a human readable text > > > > > string attribute to a capture scene. > > > > > > > > > > Here is a proposal for adding text to the framework document > > > section > > > > > 6.2.1 Capture scene attributes: > > > > > > > > > > Description attribute > > > > > > > > > > The description attribute is a human readable text string which > > > > > describes the capture scene. A provider that advertises > > > > > multiple capture scenes may use different descriptions to > > > > > differentiate between them. > > > > > > > > > > > > > > > Do we also want to add a similar description attribute to a > > > > > media capture? > > > > > > > > > > Mark Duckworth > > > > > _______________________________________________ > > > > > clue mailing list > > > > > clue@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/clue > > > > > > _______________________________________________ > > > clue mailing list > > > clue@ietf.org > > > https://www.ietf.org/mailman/listinfo/clue > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From ron.even.tlv@gmail.com Fri May 18 21:21:15 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F213F21F85B1 for ; Fri, 18 May 2012 21:21:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.197 X-Spam-Level: X-Spam-Status: No, score=-3.197 tagged_above=-999 required=5 tests=[AWL=0.402, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ySyMTkTRlKnt for ; Fri, 18 May 2012 21:21:14 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id C0FB421F85A0 for ; Fri, 18 May 2012 21:21:13 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so2331429wgb.13 for ; Fri, 18 May 2012 21:21:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language; bh=ZG/r2bEs22dic/lz/7ffun/HmgCDVQOh+SP4dDsIwEE=; b=vRdaFXwQOMdKzJ4beVd08xN0GkBrk4qlUi1D/Mrm2lQRkzIQccGe1ykuNHRi9if+T+ mr044tGfYMuldLe8hPzVbcjLF7E9xuBwcddGkhWPJ7fJ1x/hyppn+iceGtjPk0i6vgvk bjDWqT8MeQnqS5oqa32mWpxy6FXvPmKVX/hGiQJkaENJy5Giu3e/kWYRs3yweJwxSWFy IzYW+3LE+Z39ZgAvMRnVPSckXcbh3UpVodmWT4Cl1OYm/jQe1Sh73Vnk8NNVNXgZ51aX KLeYGjXazfGCSp+Cdxh9VqbO5zUrD7t05ZoEKQSiBZtaaz28q2Bry+zM0iuGRyphZf6r CRlg== Received: by 10.180.85.129 with SMTP id h1mr7344367wiz.2.1337401272328; Fri, 18 May 2012 21:21:12 -0700 (PDT) Received: from windows8d787f9 (bzq-79-177-198-116.red.bezeqint.net. [79.177.198.116]) by mx.google.com with ESMTPS id f19sm9429526wiw.11.2012.05.18.21.21.10 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 18 May 2012 21:21:11 -0700 (PDT) From: "Roni Even" To: "'Paul Kyzivat'" , References: <44C6B6B2D0CF424AA90B6055548D7A6102FD83676A@CRPMBOXPRD01.polycom.com> <4fb6aa67.0a4cb40a.6f40.ffffb870@mx.google.com> <44C6B6B2D0CF424AA90B6055548D7A6102FD836877@CRPMBOXPRD01.polycom.com> <4fb6baca.a46ab40a.1103.ffffc656@mx.google.com> <4FB6C01D.9030004@alum.mit.edu> In-Reply-To: <4FB6C01D.9030004@alum.mit.edu> Date: Sat, 19 May 2012 07:18:41 +0300 Message-ID: <4fb71fb7.f34bb40a.68b5.0ea9@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: Ac01PevclZjwegd2R5qur5P0pygVgwAN2crQ Content-Language: en-us Subject: Re: [clue] Ticket #8 - add description text to a capture scene X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 19 May 2012 04:21:15 -0000 Paul, This is OK if we have the scale attribute as mandatory or at least define the default value and mandate that media captures must supply area of capture information based on the scale parameter. I think this will clarify what a scene is since it includes all entities that have spatial relations. I do not think that presentation has a spatial relation to a room. If someone wants to include the presentation it will be good to say how to render it with regards to the rest of the scene Roni > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Paul Kyzivat > Sent: Saturday, May 19, 2012 12:33 AM > To: clue@ietf.org > Subject: Re: [clue] Ticket #8 - add description text to a capture scene > > On 5/18/12 5:08 PM, Roni Even wrote: > > Hi Mark, > > I think that this goes back to the question of how we define a > capture > > scene. Just saying that each has a unique co-ordinate system is not > > enough unless we are saying that all media captures inside a capture > > scene MUST provide spatial information using the same co-ordinate > systems and units. > > AFAIK we did decide this. Isn't that why it was decided that that the > scale attribute is associated with the capture scene and not with the > individual capture sets? > > > This means that the units can be part of the capture scene. > > They are, in 6.2.1 of the framework, not in 6.1.1. > > > It will also > > mean that room video and presentation are different capture scenes. I > > think that such definition will be in-line with the name "scene" > > In some cases it may make sense for the presentation to be in the same > scene as the room video, but there are also cases where having them > separate makes sense. Unless we find some compelling reason to nail it > down one way or another. > > (E.g. If the presentation is being shown on a screen in the room, and > the presenter is pointing to that screen, then it may make sense to > have the presenter in one capture, the presentation in another, with > both in the same scene, so there is enough info to display them both in > a way that the pointing makes sense.) > > Thanks, > Paul > > > Roni > > > >> -----Original Message----- > >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf > >> Of Duckworth, Mark > >> Sent: Friday, May 18, 2012 11:47 PM > >> To: clue@ietf.org > >> Subject: Re: [clue] Ticket #8 - add description text to a capture > >> scene > >> > >> Hi Roni, > >> > >> Thanks for the comments. > >> I didn't mean to say this proposed description attribute is enough > to > >> resolve Ticket #8, only that I thought the group agreed we should > add > >> the attribute to the framework, related to this ticket. > >> > >> Yes each capture scene is identified by a different coordinate > space. > >> From the framework: > >> "A provider can express spatial relationships between media > >> captures > >> that are included in the same capture scene. But there is no > >> spatial > >> relationship between media captures that are in different > >> capture scenes." > >> > >> I think the typical case is for room video and presentation video to > >> be in separate capture scenes. From the framework: > >> "A media provider might typically use one capture > >> scene for main participant media and another capture scene for > a > >> computer generated presentation." > >> > >> I remember people saying it would not be a good idea to prohibit > >> putting a room video capture and a presentation capture into the > same > >> capture scene, but I don't know of a case when that would be > desired. > >> You suggest maybe having a purpose attribute for the capture scene. > >> If we do that, does that mean every media capture in that scene has > that > >> same purpose? That is okay with me, but I thought others might > >> object. > >> > >> For the whole system description, I thought there is already a > >> standard way to provide "caller ID" information that serves that > >> purpose. Is that true? > >> > >> Regards, > >> Mark > >> > >>> -----Original Message----- > >>> From: Roni Even [mailto:ron.even.tlv@gmail.com] > >>> Sent: Friday, May 18, 2012 3:58 PM > >>> To: Duckworth, Mark; clue@ietf.org > >>> Subject: RE: [clue] Ticket #8 - add description text to a capture > >>> scene > >>> > >>> Hi Mark, > >>> I am not sure about this agreement. My view is that we first need > to > >>> understand what is meant by multiple capture scenes. For example is > >>> each identified by a separate co-ordinate space. > >>> When we have a room video and presentation is it two capture scene, > >> if > >>> not then how do I provide the area of interest for the presentation > >> if > >>> the video room is in real co-ordinate (mm). > >>> If they are not the same we need to have a purpose value for the > >>> capture scene which is machine readable. > >>> > >>> I do not object having a human readable description but it is not > >>> enough and it does not provide a way to differentiate between them. > >>> What you can say is that a machine readable description can be used > >> by > >>> a user (!!!!) to select a capture scene if the information is > >> rendered > >>> on a monitor allowing hime to select as part of a menu system. > >>> > >>> As for having user readable information for media capture it can be > >> as > >>> useful as the capture scene description. I think that an important > >>> description is the whole system description ( e.g. Mark's home TP > >>> system) > >>> > >>> Roni Even > >>> > >>> > >>>> -----Original Message----- > >>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On > >> Behalf > >>>> Of Duckworth, Mark > >>>> Sent: Friday, May 18, 2012 7:57 PM > >>>> To: clue@ietf.org > >>>> Subject: [clue] Ticket #8 - add description text to a capture > scene > >>>> > >>>> Regarding Ticket #8 - How consumer differentiates between multiple > >>>> capture scenes. > >>>> We discussed this a bit on the list, and on the April 10 phone > >> meeting. > >>>> I think the group agreed we should add a human readable text > string > >>>> attribute to a capture scene. > >>>> > >>>> Here is a proposal for adding text to the framework document > >> section > >>>> 6.2.1 Capture scene attributes: > >>>> > >>>> Description attribute > >>>> > >>>> The description attribute is a human readable text string which > >>>> describes the capture scene. A provider that advertises multiple > >>>> capture scenes may use different descriptions to differentiate > >>>> between them. > >>>> > >>>> > >>>> Do we also want to add a similar description attribute to a media > >>>> capture? > >>>> > >>>> Mark Duckworth > >>>> _______________________________________________ > >>>> clue mailing list > >>>> clue@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/clue > >> > >> _______________________________________________ > >> clue mailing list > >> clue@ietf.org > >> https://www.ietf.org/mailman/listinfo/clue > > > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From pkyzivat@alum.mit.edu Sat May 19 09:58:54 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D07B21F85F6 for ; Sat, 19 May 2012 09:58:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.366 X-Spam-Level: X-Spam-Status: No, score=-2.366 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8qA2U4uMsgJh for ; Sat, 19 May 2012 09:58:53 -0700 (PDT) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [76.96.59.243]) by ietfa.amsl.com (Postfix) with ESMTP id B3C0521F85EF for ; Sat, 19 May 2012 09:58:52 -0700 (PDT) Received: from omta03.westchester.pa.mail.comcast.net ([76.96.62.27]) by qmta13.westchester.pa.mail.comcast.net with comcast id Bsu21j0010bG4ec5DsyrLE; Sat, 19 May 2012 16:58:51 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta03.westchester.pa.mail.comcast.net with comcast id Bsyq1j00P07duvL3PsyqvD; Sat, 19 May 2012 16:58:51 +0000 Message-ID: <4FB7D14A.1060307@alum.mit.edu> Date: Sat, 19 May 2012 12:58:50 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Roni Even References: <44C6B6B2D0CF424AA90B6055548D7A6102FD83676A@CRPMBOXPRD01.polycom.com> <4fb6aa67.0a4cb40a.6f40.ffffb870@mx.google.com> <44C6B6B2D0CF424AA90B6055548D7A6102FD836877@CRPMBOXPRD01.polycom.com> <4fb6baca.a46ab40a.1103.ffffc656@mx.google.com> <4FB6C01D.9030004@alum.mit.edu> <4fb71fb7.f34bb40a.68b5.0ea9@mx.google.com> In-Reply-To: <4fb71fb7.f34bb40a.68b5.0ea9@mx.google.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: clue@ietf.org Subject: Re: [clue] Ticket #8 - add description text to a capture scene X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 19 May 2012 16:58:54 -0000 On 5/19/12 12:18 AM, Roni Even wrote: > Paul, > This is OK if we have the scale attribute as mandatory or at least define > the default value and mandate that media captures must supply area of > capture information based on the scale parameter. I agree that the framework isn't very clear on this. There are also some decisions to be made on how optional some of this information is: - I *think* what is currently written implies that all captures in a scene that supply area of capture must do so using the common scale for the scene. But it seems that it would still be legal to provide area of capture for some captures in the scene and omit it for other captures in the scene. - We could instead say that all captures in the scene must have an area of capture, except if the scene capture omits the scale attr or specifies it as "no scale". > I think this will clarify what a scene is since it includes all entities > that have spatial relations. > I do not think that presentation has a spatial relation to a room. If > someone wants to include the presentation it will be good to say how to > render it with regards to the rest of the scene What did you think of my example? (In the message you were replying to.) I have to admit that I haven't seen a presentation handled in any of the (Cisco) TP rooms I have been in. But ISTM there are at least two ways that presentations can be handled, somewhat related to room layout. If you have the typical TP layout I have seen, with people at a desk facing cameras and displays depicting remote people at a desk, then there is no distinguished presenter/chair. Anybody could be presenting. This works ok if everybody has a computer or workstation in front of them that can be used to present, or to view a presentation. Then the presentation doesn't have any spatial relationship to the room. If you want to have a more formal presentation, then you might want to have a speaker at a podium facing the other participants in his room. Then you might want to have a display for the presentation behind or to the side of the presenter and facing the other participants in the room. The presenter can then point at this display. The participants in the room would understand this pointing. This requires a camera facing the presenter (opposite direction of other cameras in the room). To make this work for remote rooms, you would want the presenter and the presentation displayed in a similar relationship to one another. So the capture of the presenter and the presentation capture should be in the same scene. It could be the same scene as the captures of the other participants in the room, or it could be in a different scene. (The implications of each are a little fuzzy to me right now.) Thanks, Paul > Roni > >> -----Original Message----- >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of >> Paul Kyzivat >> Sent: Saturday, May 19, 2012 12:33 AM >> To: clue@ietf.org >> Subject: Re: [clue] Ticket #8 - add description text to a capture scene >> >> On 5/18/12 5:08 PM, Roni Even wrote: >>> Hi Mark, >>> I think that this goes back to the question of how we define a >> capture >>> scene. Just saying that each has a unique co-ordinate system is not >>> enough unless we are saying that all media captures inside a capture >>> scene MUST provide spatial information using the same co-ordinate >> systems and units. >> >> AFAIK we did decide this. Isn't that why it was decided that that the >> scale attribute is associated with the capture scene and not with the >> individual capture sets? >> >>> This means that the units can be part of the capture scene. >> >> They are, in 6.2.1 of the framework, not in 6.1.1. >> >>> It will also >>> mean that room video and presentation are different capture scenes. I >>> think that such definition will be in-line with the name "scene" >> >> In some cases it may make sense for the presentation to be in the same >> scene as the room video, but there are also cases where having them >> separate makes sense. Unless we find some compelling reason to nail it >> down one way or another. >> >> (E.g. If the presentation is being shown on a screen in the room, and >> the presenter is pointing to that screen, then it may make sense to >> have the presenter in one capture, the presentation in another, with >> both in the same scene, so there is enough info to display them both in >> a way that the pointing makes sense.) >> >> Thanks, >> Paul >> >>> Roni >>> >>>> -----Original Message----- >>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf >>>> Of Duckworth, Mark >>>> Sent: Friday, May 18, 2012 11:47 PM >>>> To: clue@ietf.org >>>> Subject: Re: [clue] Ticket #8 - add description text to a capture >>>> scene >>>> >>>> Hi Roni, >>>> >>>> Thanks for the comments. >>>> I didn't mean to say this proposed description attribute is enough >> to >>>> resolve Ticket #8, only that I thought the group agreed we should >> add >>>> the attribute to the framework, related to this ticket. >>>> >>>> Yes each capture scene is identified by a different coordinate >> space. >>>> From the framework: >>>> "A provider can express spatial relationships between media >>>> captures >>>> that are included in the same capture scene. But there is no >>>> spatial >>>> relationship between media captures that are in different >>>> capture scenes." >>>> >>>> I think the typical case is for room video and presentation video to >>>> be in separate capture scenes. From the framework: >>>> "A media provider might typically use one capture >>>> scene for main participant media and another capture scene for >> a >>>> computer generated presentation." >>>> >>>> I remember people saying it would not be a good idea to prohibit >>>> putting a room video capture and a presentation capture into the >> same >>>> capture scene, but I don't know of a case when that would be >> desired. >>>> You suggest maybe having a purpose attribute for the capture scene. >>>> If we do that, does that mean every media capture in that scene has >> that >>>> same purpose? That is okay with me, but I thought others might >>>> object. >>>> >>>> For the whole system description, I thought there is already a >>>> standard way to provide "caller ID" information that serves that >>>> purpose. Is that true? >>>> >>>> Regards, >>>> Mark >>>> >>>>> -----Original Message----- >>>>> From: Roni Even [mailto:ron.even.tlv@gmail.com] >>>>> Sent: Friday, May 18, 2012 3:58 PM >>>>> To: Duckworth, Mark; clue@ietf.org >>>>> Subject: RE: [clue] Ticket #8 - add description text to a capture >>>>> scene >>>>> >>>>> Hi Mark, >>>>> I am not sure about this agreement. My view is that we first need >> to >>>>> understand what is meant by multiple capture scenes. For example is >>>>> each identified by a separate co-ordinate space. >>>>> When we have a room video and presentation is it two capture scene, >>>> if >>>>> not then how do I provide the area of interest for the presentation >>>> if >>>>> the video room is in real co-ordinate (mm). >>>>> If they are not the same we need to have a purpose value for the >>>>> capture scene which is machine readable. >>>>> >>>>> I do not object having a human readable description but it is not >>>>> enough and it does not provide a way to differentiate between them. >>>>> What you can say is that a machine readable description can be used >>>> by >>>>> a user (!!!!) to select a capture scene if the information is >>>> rendered >>>>> on a monitor allowing hime to select as part of a menu system. >>>>> >>>>> As for having user readable information for media capture it can be >>>> as >>>>> useful as the capture scene description. I think that an important >>>>> description is the whole system description ( e.g. Mark's home TP >>>>> system) >>>>> >>>>> Roni Even >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On >>>> Behalf >>>>>> Of Duckworth, Mark >>>>>> Sent: Friday, May 18, 2012 7:57 PM >>>>>> To: clue@ietf.org >>>>>> Subject: [clue] Ticket #8 - add description text to a capture >> scene >>>>>> >>>>>> Regarding Ticket #8 - How consumer differentiates between multiple >>>>>> capture scenes. >>>>>> We discussed this a bit on the list, and on the April 10 phone >>>> meeting. >>>>>> I think the group agreed we should add a human readable text >> string >>>>>> attribute to a capture scene. >>>>>> >>>>>> Here is a proposal for adding text to the framework document >>>> section >>>>>> 6.2.1 Capture scene attributes: >>>>>> >>>>>> Description attribute >>>>>> >>>>>> The description attribute is a human readable text string which >>>>>> describes the capture scene. A provider that advertises multiple >>>>>> capture scenes may use different descriptions to differentiate >>>>>> between them. >>>>>> >>>>>> >>>>>> Do we also want to add a similar description attribute to a media >>>>>> capture? >>>>>> >>>>>> Mark Duckworth >>>>>> _______________________________________________ >>>>>> clue mailing list >>>>>> clue@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/clue >>>> >>>> _______________________________________________ >>>> clue mailing list >>>> clue@ietf.org >>>> https://www.ietf.org/mailman/listinfo/clue >>> >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >>> >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue > > From Mark.Duckworth@polycom.com Mon May 21 15:14:21 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39FA521F8535 for ; Mon, 21 May 2012 15:14:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rs+I2Xv5jAGS for ; Mon, 21 May 2012 15:14:20 -0700 (PDT) Received: from Crpehubprd01.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 9600B21F8504 for ; Mon, 21 May 2012 15:14:19 -0700 (PDT) Received: from Crpmboxprd01.polycom.com ([fe80::ad68:5a0:c919:66b6]) by Crpehubprd01.polycom.com ([fe80::5efe:10.236.0.158%14]) with mapi; Mon, 21 May 2012 15:14:17 -0700 From: "Duckworth, Mark" To: Stephan Wenger , "clue@ietf.org" Date: Mon, 21 May 2012 15:14:14 -0700 Thread-Topic: Ticket #9 - axis of capture description Thread-Index: Ac03nw5TzZOcf7sESlmBc00DHwCTSQ== Message-ID: <44C6B6B2D0CF424AA90B6055548D7A6102FD836DA5@CRPMBOXPRD01.polycom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [clue] Ticket #9 - axis of capture description X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 May 2012 22:14:21 -0000 Hi Stephan, Do you want to discuss your proposal for describing the "capture axis" at t= he upcoming interim meeting, as part of a framework discussion? Do you hav= e any more details yet? Mark > -----Original Message----- > From: Stephan Wenger [mailto:stewe@stewe.org] > Sent: Tuesday, March 06, 2012 7:35 PM > To: Paul Kyzivat; Duckworth, Mark > Cc: clue@ietf.org > Subject: Re: [clue] Language re capture axis >=20 > With the understanding that "out of this version" means "out of this > interation of the I-D", I'm fine. I still want this in the published RFC= . > Same goes for (de)composition info. > I will propose text as soon as I find the cycles (not before the Paris I-= D > deadline). >=20 > Stephan >=20 >=20 > On 3.6.2012 14:51 , "Paul Kyzivat" wrote: >=20 > >On 3/5/12 1:29 PM, Duckworth, Mark wrote: > >> As editor, it seems I should leave this out of the next version. Okay= ? > > > >I'm ok with leaving any mention of it out, assuming those who were > >concerned about it (Stephan) are ok with that. > > > > Paul > > > >> Otherwise, I would appreciate having interested parties propose new > >>text to discuss on the mailing list, considering Paul's desire to have > >>more specific text than what we have previously discussed. > >> > >> Thanks, > >> Mark > >> > >>> -----Original Message----- > >>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > >>> Sent: Thursday, March 01, 2012 4:53 PM > >>> To: Duckworth, Mark > >>> Cc: clue@ietf.org > >>> Subject: Re: [clue] Language re capture axis > >>> > >>> On 2/29/12 11:14 AM, Duckworth, Mark wrote: > >>>> Paul and Stephan, > >>>> > >>>> Personally, I'd rather just leave it out altogether because I think > >>>>it doesn't > >>> add anything that needs to be standardized. But Stephan thought it > >>>was important, so I was trying to find a way to say it in an > >>>"accurate enough" way. > >>> > >>> If there is no widespread interest in having this, and those who > >>>have asked about it are happy without, then I'm fine with leaving it > >>>out. > >>> > >>> If it is to be mentioned, with the idea that the recipient might use > >>>it for something, then I think it should be made clear how it can be > >>>determined. > >>> > >>> Thanks, > >>> Paul > >>> > >>>> Mark > >>>> > >>>>> -----Original Message----- > >>>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On > >>>>> Behalf Of Paul Kyzivat > >>>>> Sent: Wednesday, February 29, 2012 10:56 AM > >>>>> To: clue@ietf.org > >>>>> Subject: Re: [clue] Language re capture axis > >>>>> > >>>>> On 2/29/12 10:10 AM, Duckworth, Mark wrote: > >>>>>> Hi Stephan, > >>>>>> > >>>>>> I agree in principle with your suggestion, but I think your > >>>>>> suggested text is not mathematically accurate. I think the axis > >>>>>> of capture doesn't go to the center of the area of capture. For > >>>>>> example, if the camera is pointed at the area of capture at an > >>>>>> angle, the center point of the area would not line up with the > >>>>>> center point of the camera's field of view (which defines the axis= ). > >>>>>> > >>>>>> So rather than try to get into the mathematical details, how > >>>>>>about > >>>>>>this: > >>>>>> > >>>>>> "Note that, for the purpose of receiver-side geometric > >>>>>> correction, it can be assumed that the axis of capture of > >>>>>> directional capture devices (cameras, directional microphones > >>>>>> etc.) can be calculated from the coordinates of the point of captu= re > and area of capture." > >>>>> > >>>>> IMO this is dangerously vague. Presumably there is a real axis of > >>>>>capture. > >>>>> Hopefully there is a well defined algorithm for deriving the axis > >>>>>from the available data, so that the recipient will determine the > >>>>>actual axis. If so, then it should be specified or referenced from > >>>>>some source. Otherwise we run the risk that not all will correctly > >>>>>derive > >>> the axis. > >>>>> > >>>>> Thanks, > >>>>> Paul > >>>>> > >>>>>> Mark > >>>>>> > >>>>>> *From:*clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On > >>>>>> Behalf Of *Stephan Wenger > >>>>>> *Sent:* Wednesday, February 15, 2012 11:04 AM > >>>>>> *To:* clue@ietf.org > >>>>>> *Subject:* [clue] Language re capture axis > >>>>>> > >>>>>> Hi, > >>>>>> > >>>>>> The issue I mentioned in the meeting is that nowhere in the > >>>>>> framework (as far as I recall) the axis of capture of a video > >>>>>> capture (or directional audio capture-anything that is not > >>>>>> omnidirectional) is undefined. Without that axis being defined, > >>>>>> receiver-side geometric correction is not possible. > >>>>>> > >>>>>> The issue could be solved in two ways: include attributes, per > >>>>>> capture, indicating angle of capture in 3D space (relative to > >>>>>> what???), or by making the bold assumption that the coordinates > >>>>>> defining area of capture plus capture point define the axis of > >>>>>> capture. I suggest the latter as it is easy to implement and (I > >>>>>> believe) > >>>>> practical. > >>>>>> > >>>>>> The language could be something like: > >>>>>> > >>>>>> " > >>>>>> > >>>>>> Note that, for the purpose of receiver-side geometric correction, > >>>>>> it can be assumed that the axis of capture of directional capture > >>>>>> devices (cameras, directional microphones etc.) is the line from > >>>>>> the capture point to the center of the plane of capture. > >>>>>> > >>>>>> " > >>>>>> > >>>>>> Stephan > >>>>>> > >>>>>> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> clue mailing list > >>>>>> clue@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/clue > >>>>> > >>>>> _______________________________________________ > >>>>> clue mailing list > >>>>> clue@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/clue > >>>> > >> > >> > > > >_______________________________________________ > >clue mailing list > >clue@ietf.org > >https://www.ietf.org/mailman/listinfo/clue > > >=20 From stewe@stewe.org Mon May 21 15:47:53 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C68E21F859F for ; Mon, 21 May 2012 15:47:53 -0700 (PDT) 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=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZqT478Vy41ix for ; Mon, 21 May 2012 15:47:52 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe004.messaging.microsoft.com [216.32.180.14]) by ietfa.amsl.com (Postfix) with ESMTP id 9125621F8597 for ; Mon, 21 May 2012 15:47:52 -0700 (PDT) Received: from mail106-va3-R.bigfish.com (10.7.14.243) by VA3EHSOBE003.bigfish.com (10.7.40.23) with Microsoft SMTP Server id 14.1.225.23; Mon, 21 May 2012 22:47:38 +0000 Received: from mail106-va3 (localhost [127.0.0.1]) by mail106-va3-R.bigfish.com (Postfix) with ESMTP id 7FEA6160448; Mon, 21 May 2012 22:47:38 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.133; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0710HT002.namprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -34 X-BigFish: PS-34(zzbb2dI9371I542M1432N98dK4015Izz1202h1082kzz1033IL8275bh8275dhz2fh2a8h668h839h944he5bhf0ah) Received-SPF: pass (mail106-va3: domain of stewe.org designates 157.56.240.133 as permitted sender) client-ip=157.56.240.133; envelope-from=stewe@stewe.org; helo=BL2PRD0710HT002.namprd07.prod.outlook.com ; .outlook.com ; Received: from mail106-va3 (localhost.localdomain [127.0.0.1]) by mail106-va3 (MessageSwitch) id 1337640455442416_3905; Mon, 21 May 2012 22:47:35 +0000 (UTC) Received: from VA3EHSMHS009.bigfish.com (unknown [10.7.14.239]) by mail106-va3.bigfish.com (Postfix) with ESMTP id 645D4140194; Mon, 21 May 2012 22:47:35 +0000 (UTC) Received: from BL2PRD0710HT002.namprd07.prod.outlook.com (157.56.240.133) by VA3EHSMHS009.bigfish.com (10.7.99.19) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 21 May 2012 22:47:32 +0000 Received: from BL2PRD0710MB349.namprd07.prod.outlook.com ([169.254.1.64]) by BL2PRD0710HT002.namprd07.prod.outlook.com ([10.255.102.37]) with mapi id 14.16.0164.001; Mon, 21 May 2012 22:47:45 +0000 From: Stephan Wenger To: "Duckworth, Mark" , "clue@ietf.org" Thread-Topic: Ticket #9 - axis of capture description Thread-Index: Ac03nw5TzZOcf7sESlmBc00DHwCTSf//k/4A Date: Mon, 21 May 2012 22:47:44 +0000 Message-ID: In-Reply-To: <44C6B6B2D0CF424AA90B6055548D7A6102FD836DA5@CRPMBOXPRD01.polycom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.102.4] Content-Type: text/plain; charset="us-ascii" Content-ID: <6BF450579E834940BC0BA8D951C795EF@namprd07.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: stewe.org Subject: Re: [clue] Ticket #9 - axis of capture description X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 May 2012 22:47:53 -0000 Uh. Yes and No to your questions. I will have a text proposal ready by the interim, or shortly before. And perhaps also a slide deck. Good? Stephan On 5.21.2012 15:14 , "Duckworth, Mark" wrote: >Hi Stephan, >Do you want to discuss your proposal for describing the "capture axis" at >the upcoming interim meeting, as part of a framework discussion? Do you >have any more details yet? > >Mark > >> -----Original Message----- >> From: Stephan Wenger [mailto:stewe@stewe.org] >> Sent: Tuesday, March 06, 2012 7:35 PM >> To: Paul Kyzivat; Duckworth, Mark >> Cc: clue@ietf.org >> Subject: Re: [clue] Language re capture axis >>=20 >> With the understanding that "out of this version" means "out of this >> interation of the I-D", I'm fine. I still want this in the published >>RFC. >> Same goes for (de)composition info. >> I will propose text as soon as I find the cycles (not before the Paris >>I-D >> deadline). >>=20 >> Stephan >>=20 >>=20 >> On 3.6.2012 14:51 , "Paul Kyzivat" wrote: >>=20 >> >On 3/5/12 1:29 PM, Duckworth, Mark wrote: >> >> As editor, it seems I should leave this out of the next version. >>Okay? >> > >> >I'm ok with leaving any mention of it out, assuming those who were >> >concerned about it (Stephan) are ok with that. >> > >> > Paul >> > >> >> Otherwise, I would appreciate having interested parties propose new >> >>text to discuss on the mailing list, considering Paul's desire to have >> >>more specific text than what we have previously discussed. >> >> >> >> Thanks, >> >> Mark >> >> >> >>> -----Original Message----- >> >>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >> >>> Sent: Thursday, March 01, 2012 4:53 PM >> >>> To: Duckworth, Mark >> >>> Cc: clue@ietf.org >> >>> Subject: Re: [clue] Language re capture axis >> >>> >> >>> On 2/29/12 11:14 AM, Duckworth, Mark wrote: >> >>>> Paul and Stephan, >> >>>> >> >>>> Personally, I'd rather just leave it out altogether because I think >> >>>>it doesn't >> >>> add anything that needs to be standardized. But Stephan thought it >> >>>was important, so I was trying to find a way to say it in an >> >>>"accurate enough" way. >> >>> >> >>> If there is no widespread interest in having this, and those who >> >>>have asked about it are happy without, then I'm fine with leaving it >> >>>out. >> >>> >> >>> If it is to be mentioned, with the idea that the recipient might use >> >>>it for something, then I think it should be made clear how it can be >> >>>determined. >> >>> >> >>> Thanks, >> >>> Paul >> >>> >> >>>> Mark >> >>>> >> >>>>> -----Original Message----- >> >>>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On >> >>>>> Behalf Of Paul Kyzivat >> >>>>> Sent: Wednesday, February 29, 2012 10:56 AM >> >>>>> To: clue@ietf.org >> >>>>> Subject: Re: [clue] Language re capture axis >> >>>>> >> >>>>> On 2/29/12 10:10 AM, Duckworth, Mark wrote: >> >>>>>> Hi Stephan, >> >>>>>> >> >>>>>> I agree in principle with your suggestion, but I think your >> >>>>>> suggested text is not mathematically accurate. I think the axis >> >>>>>> of capture doesn't go to the center of the area of capture. For >> >>>>>> example, if the camera is pointed at the area of capture at an >> >>>>>> angle, the center point of the area would not line up with the >> >>>>>> center point of the camera's field of view (which defines the >>axis). >> >>>>>> >> >>>>>> So rather than try to get into the mathematical details, how >> >>>>>>about >> >>>>>>this: >> >>>>>> >> >>>>>> "Note that, for the purpose of receiver-side geometric >> >>>>>> correction, it can be assumed that the axis of capture of >> >>>>>> directional capture devices (cameras, directional microphones >> >>>>>> etc.) can be calculated from the coordinates of the point of >>capture >> and area of capture." >> >>>>> >> >>>>> IMO this is dangerously vague. Presumably there is a real axis of >> >>>>>capture. >> >>>>> Hopefully there is a well defined algorithm for deriving the axis >> >>>>>from the available data, so that the recipient will determine the >> >>>>>actual axis. If so, then it should be specified or referenced from >> >>>>>some source. Otherwise we run the risk that not all will correctly >> >>>>>derive >> >>> the axis. >> >>>>> >> >>>>> Thanks, >> >>>>> Paul >> >>>>> >> >>>>>> Mark >> >>>>>> >> >>>>>> *From:*clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On >> >>>>>> Behalf Of *Stephan Wenger >> >>>>>> *Sent:* Wednesday, February 15, 2012 11:04 AM >> >>>>>> *To:* clue@ietf.org >> >>>>>> *Subject:* [clue] Language re capture axis >> >>>>>> >> >>>>>> Hi, >> >>>>>> >> >>>>>> The issue I mentioned in the meeting is that nowhere in the >> >>>>>> framework (as far as I recall) the axis of capture of a video >> >>>>>> capture (or directional audio capture-anything that is not >> >>>>>> omnidirectional) is undefined. Without that axis being defined, >> >>>>>> receiver-side geometric correction is not possible. >> >>>>>> >> >>>>>> The issue could be solved in two ways: include attributes, per >> >>>>>> capture, indicating angle of capture in 3D space (relative to >> >>>>>> what???), or by making the bold assumption that the coordinates >> >>>>>> defining area of capture plus capture point define the axis of >> >>>>>> capture. I suggest the latter as it is easy to implement and (I >> >>>>>> believe) >> >>>>> practical. >> >>>>>> >> >>>>>> The language could be something like: >> >>>>>> >> >>>>>> " >> >>>>>> >> >>>>>> Note that, for the purpose of receiver-side geometric correction, >> >>>>>> it can be assumed that the axis of capture of directional capture >> >>>>>> devices (cameras, directional microphones etc.) is the line from >> >>>>>> the capture point to the center of the plane of capture. >> >>>>>> >> >>>>>> " >> >>>>>> >> >>>>>> Stephan >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> _______________________________________________ >> >>>>>> clue mailing list >> >>>>>> clue@ietf.org >> >>>>>> https://www.ietf.org/mailman/listinfo/clue >> >>>>> >> >>>>> _______________________________________________ >> >>>>> clue mailing list >> >>>>> clue@ietf.org >> >>>>> https://www.ietf.org/mailman/listinfo/clue >> >>>> >> >> >> >> >> > >> >_______________________________________________ >> >clue mailing list >> >clue@ietf.org >> >https://www.ietf.org/mailman/listinfo/clue >> > >>=20 > > From mary.ietf.barnes@gmail.com Mon May 21 16:04:07 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A12D821F84B3 for ; Mon, 21 May 2012 16:04:07 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ggnZvyr5P7eE for ; Mon, 21 May 2012 16:04:07 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 164B421F84A7 for ; Mon, 21 May 2012 16:04:06 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so4521346vbb.31 for ; Mon, 21 May 2012 16:04:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=2c9cjVowh10oWFwK8Xlnv4nRHIL8xyY4sDOuIJL3ea8=; b=a9jODDb3J2EhGGib3psN3RK/8QA+dm4SPLcThGDn+LDJp9s5/t7CS/P6US/AspBPpV f78wpEkyMWLrcOFAZSaTInmR3434vvdP+QZbSd+ZRP1mgupoy80LNlZuTK2Z5ze4Fa6K Gr2nettcIKAsglpHZNFowOBIDQE/qN5uHqiPj4uFuuw9pU62UinjDkvx+PiFIr+V9Gg1 JDnB4HWpAcRpyOWbMSfJ/UgtWMQHzhSm5OTHqNNUwGgnXX2JiEmAS3b0+tttN80UNbUB AUoTnR1s3XA3fIfd4P9LkkmqWrsMk7LGb/KUhGxgPc/jBcWH9qCb+RgbllAmvln7BLMx b2tg== MIME-Version: 1.0 Received: by 10.52.173.209 with SMTP id bm17mr10470845vdc.54.1337641446348; Mon, 21 May 2012 16:04:06 -0700 (PDT) Received: by 10.52.22.143 with HTTP; Mon, 21 May 2012 16:04:06 -0700 (PDT) Date: Mon, 21 May 2012 18:04:06 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=bcaec51b9bf53f19fc04c093eb21 Subject: [clue] Topic: CLUE WG DT meeting tomorrow (May 22 @ 9am central) X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 May 2012 23:04:07 -0000 --bcaec51b9bf53f19fc04c093eb21 Content-Type: text/plain; charset=ISO-8859-1 Hi all, Since it's been a few weeks since we have had a call, it would be good for us to have one this week and discuss some of the recent issues that have been discussed on the mailing list. While I don't necessarily like a meeting because people aren't responding on the mailing list, I think some of these topics would benefit from non-email discussion. 1) Criteria for CLUE signaling: http://www.ietf.org/mail-archive/web/clue/current/msg01433.html [Note: Christer cannot make this meeting, but we can still review and decide whether we agree this is a good starting point] 2) Ticket #8: add description text to a capture scene http://www.ietf.org/mail-archive/web/clue/current/msg01442.html 3) Ticket #8: capture scene coordinates and content attribute http://www.ietf.org/mail-archive/web/clue/current/msg01446.html Regards, Mary. --bcaec51b9bf53f19fc04c093eb21 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all,

Since it's been a few weeks since we have ha= d a call, it would be good for us to have one this week and discuss some of= the recent issues that have been discussed on the mailing list. =A0While I= don't necessarily like a meeting because people aren't responding = on the mailing list, I think some of these topics would benefit from non-em= ail discussion.

1) Criteria for CLUE signaling:
http://www.i= etf.org/mail-archive/web/clue/current/msg01433.html =A0[Note: Christer = cannot make this meeting, but we can still review and decide whether we agr= ee this is a good starting point]

2) Ticket #8: add description text to a capture scene

3) Ticket #8: capture scene coordinates and content att= ribute

Regards,
Mary.
--bcaec51b9bf53f19fc04c093eb21-- From marshall.eubanks@gmail.com Mon May 21 16:15:04 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D364221F84CE for ; Mon, 21 May 2012 16:15:04 -0700 (PDT) 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=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6BsdsfO3TBIR for ; Mon, 21 May 2012 16:15:04 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id EC07C21F849A for ; Mon, 21 May 2012 16:15:03 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so4468484lbb.31 for ; Mon, 21 May 2012 16:15:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=HVLUer2SGMMjD8VOYrlRpj7C/e7/MGVJUjYrNppvqWs=; b=Ys/cChoOme4UlzNN38XHrXoXc2yCwekIXTU27d+uColsiw3XwDLlglSFUxVh6ZsOh+ 0n5PidbGzqPDcxRiwM+CsCa30aLicFMMBs4pAJxZV9bgMuGFMphagWUx3i5DA8yPYGk2 AOCxdgifSzfpdFCCCLaa4SVOsxdgKuiwXFTlhlH5y5TjQodSHa0RlRTFxhkw8NsmmWJa xBwq2gXUY1GvRmu5xChLqKuYnCa74u677qpU1BMxsdU6VAUNmN8re8DeRn3LePIz21V2 Yld6743OYNx+uyhvGWfgXIFjOZ6KDyZN3FuKbGBFIDK6qrdt2iJLuVWtsFuR8oL4A7CK Fbdg== MIME-Version: 1.0 Received: by 10.152.162.68 with SMTP id xy4mr21347608lab.49.1337642102954; Mon, 21 May 2012 16:15:02 -0700 (PDT) Received: by 10.112.56.13 with HTTP; Mon, 21 May 2012 16:15:02 -0700 (PDT) In-Reply-To: References: Date: Mon, 21 May 2012 19:15:02 -0400 Message-ID: From: Marshall Eubanks To: Mary Barnes Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: CLUE Subject: Re: [clue] Topic: CLUE WG DT meeting tomorrow (May 22 @ 9am central) X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 May 2012 23:15:05 -0000 I am afraid that I am booked tomorrow and will have to send regrets. Marshall On Mon, May 21, 2012 at 7:04 PM, Mary Barnes w= rote: > Hi all, > > Since it's been a few weeks since we have had a call, it would be good fo= r > us to have one this week and discuss some of the recent issues that have > been discussed on the mailing list. =A0While I don't necessarily like a > meeting because people aren't responding on the mailing list, I think som= e > of these topics would benefit from non-email discussion. > > 1) Criteria for CLUE signaling: > http://www.ietf.org/mail-archive/web/clue/current/msg01433.html =A0[Note: > Christer cannot make this meeting, but we can still review and decide > whether we agree this is a good starting point] > > 2) Ticket #8: add description text to a capture scene > http://www.ietf.org/mail-archive/web/clue/current/msg01442.html > > 3) Ticket #8: capture scene coordinates and content attribute > http://www.ietf.org/mail-archive/web/clue/current/msg01446.html > > Regards, > Mary. > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From stewe@stewe.org Mon May 21 18:51:33 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB19921F854A for ; Mon, 21 May 2012 18:51:33 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N1KyIBrr1WqX for ; Mon, 21 May 2012 18:51:33 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe004.messaging.microsoft.com [216.32.181.184]) by ietfa.amsl.com (Postfix) with ESMTP id 1675021F84B6 for ; Mon, 21 May 2012 18:51:32 -0700 (PDT) Received: from mail67-ch1-R.bigfish.com (10.43.68.227) by CH1EHSOBE003.bigfish.com (10.43.70.53) with Microsoft SMTP Server id 14.1.225.23; Tue, 22 May 2012 01:51:15 +0000 Received: from mail67-ch1 (localhost [127.0.0.1]) by mail67-ch1-R.bigfish.com (Postfix) with ESMTP id 5C84018017A; Tue, 22 May 2012 01:51:15 +0000 (UTC) X-SpamScore: -15 X-BigFish: PS-15(zzc85fh14ffIzz1202h1082kzz1033IL8275bh8275dhz2fh2a8h668h839he5bhf0ahbe3k) X-Forefront-Antispam-Report: CIP:157.56.240.133; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0710HT001.namprd07.prod.outlook.com; RD:none; EFVD:NLI Received-SPF: pass (mail67-ch1: domain of stewe.org designates 157.56.240.133 as permitted sender) client-ip=157.56.240.133; envelope-from=stewe@stewe.org; helo=BL2PRD0710HT001.namprd07.prod.outlook.com ; .outlook.com ; Received: from mail67-ch1 (localhost.localdomain [127.0.0.1]) by mail67-ch1 (MessageSwitch) id 1337651472409234_16120; Tue, 22 May 2012 01:51:12 +0000 (UTC) Received: from CH1EHSMHS008.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.242]) by mail67-ch1.bigfish.com (Postfix) with ESMTP id 5FFFE480195; Tue, 22 May 2012 01:51:12 +0000 (UTC) Received: from BL2PRD0710HT001.namprd07.prod.outlook.com (157.56.240.133) by CH1EHSMHS008.bigfish.com (10.43.70.8) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 22 May 2012 01:51:11 +0000 Received: from BL2PRD0710MB349.namprd07.prod.outlook.com ([169.254.1.64]) by BL2PRD0710HT001.namprd07.prod.outlook.com ([10.255.102.36]) with mapi id 14.16.0164.004; Tue, 22 May 2012 01:51:24 +0000 From: Stephan Wenger To: Mary Barnes , CLUE Thread-Topic: [clue] Topic: CLUE WG DT meeting tomorrow (May 22 @ 9am central) Thread-Index: AQHNN6YLb0a2VS76lkOtHKVhxlmTXJbUlh0A Date: Tue, 22 May 2012 01:51:23 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.102.5] Content-Type: multipart/alternative; boundary="_000_CBE03F188739Estewesteweorg_" MIME-Version: 1.0 X-OriginatorOrg: stewe.org Subject: Re: [clue] Topic: CLUE WG DT meeting tomorrow (May 22 @ 9am central) X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 22 May 2012 01:51:33 -0000 --_000_CBE03F188739Estewesteweorg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sorry, can't attend. Stephan From: Mary Barnes > Date: Monday, 21 May, 2012 16:04 To: CLUE > Subject: [clue] Topic: CLUE WG DT meeting tomorrow (May 22 @ 9am central) Hi all, Since it's been a few weeks since we have had a call, it would be good for = us to have one this week and discuss some of the recent issues that have be= en discussed on the mailing list. While I don't necessarily like a meeting= because people aren't responding on the mailing list, I think some of thes= e topics would benefit from non-email discussion. 1) Criteria for CLUE signaling: http://www.ietf.org/mail-archive/web/clue/current/msg01433.html [Note: Chr= ister cannot make this meeting, but we can still review and decide whether = we agree this is a good starting point] 2) Ticket #8: add description text to a capture scene http://www.ietf.org/mail-archive/web/clue/current/msg01442.html 3) Ticket #8: capture scene coordinates and content attribute http://www.ietf.org/mail-archive/web/clue/current/msg01446.html Regards, Mary. --_000_CBE03F188739Estewesteweorg_ Content-Type: text/html; charset="us-ascii" Content-ID: <9D3043DE2750CE4EBF822BB6E028CC5D@namprd07.prod.outlook.com> Content-Transfer-Encoding: quoted-printable
Sorry, can't attend.
Stephan


From: Mary Barnes <mary.ietf.barnes@gmail.com>
Date: Monday, 21 May, 2012 16:04 To: CLUE <clue@ietf.org>
Subject: [clue] Topic: CLUE WG DT m= eeting tomorrow (May 22 @ 9am central)

Hi all,

Since it's been a few weeks since we have had a call, it would be good= for us to have one this week and discuss some of the recent issues that ha= ve been discussed on the mailing list.  While I don't necessarily like= a meeting because people aren't responding on the mailing list, I think some of these topics would benefit from non-e= mail discussion.

1) Criteria for CLUE signaling:
http://www.ietf.org/mail-archive/web/clue/current/msg01433.html &= nbsp;[Note: Christer cannot make this meeting, but we can still review and = decide whether we agree this is a good starting point]

2) Ticket #8: add description text to a capture scene
--_000_CBE03F188739Estewesteweorg_-- From ron.even.tlv@gmail.com Tue May 22 02:36:50 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56B4221F846B for ; Tue, 22 May 2012 02:36:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.171 X-Spam-Level: X-Spam-Status: No, score=-3.171 tagged_above=-999 required=5 tests=[AWL=0.427, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dDIKm+p+Zu5K for ; Tue, 22 May 2012 02:36:49 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 09EA821F8466 for ; Tue, 22 May 2012 02:36:48 -0700 (PDT) Received: by werb13 with SMTP id b13so3067825wer.31 for ; Tue, 22 May 2012 02:36:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:date:message-id:mime-version:content-type :x-mailer:thread-index:content-language; bh=jDhPTUYFoKOVy3VtIdBtvKJQlwbCUdfWecbqnf1OgP4=; b=IkoUJNGcmF4jZHSkZpOsrOJbdPPBFSV635CXvGlC0k0XRbKIFbR5Pk5reDfYnha8zM 11np5CgKKpjEZAj4msfeWGCAKrAUq48z1N4lQy9NBUNq7xZ/JrFJwqXuxZx60msnZWxH q93boluYwXSApk2OVrlQZFCLYMqHrPd2mSn9bhjb2XLkB3dstIqwwtMl4tlGsLzS0g2G Cc7yy5WgBoK5eLzrLsqvWTd/YCA1CClEkN3RiE/aw/rT39C8oBiVQzAYNCZdGXN1lkZQ X6TTgFoR1BPIzYMfUVWrFstG3SSv4F1fM117TZsi3vVTRQOfzy7KSZcJWF/xo1IIOFsx OV/g== Received: by 10.180.95.100 with SMTP id dj4mr12058061wib.17.1337679408068; Tue, 22 May 2012 02:36:48 -0700 (PDT) Received: from windows8d787f9 (bzq-79-177-198-116.red.bezeqint.net. [79.177.198.116]) by mx.google.com with ESMTPS id e20sm27201871wiv.7.2012.05.22.02.36.45 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 22 May 2012 02:36:47 -0700 (PDT) From: "Roni Even" To: Date: Tue, 22 May 2012 12:34:30 +0300 Message-ID: <4fbb5e2f.b448b40a.38d1.17da@mx.google.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0004_01CD3817.3E001B10" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac03/hatuWnQE2C0QJapt0gKDTdh5A== Content-Language: en-us Subject: [clue] My view if CLUE status and topics for Interim meeting X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 22 May 2012 09:36:50 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0004_01CD3817.3E001B10 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Guys, I think that we are in a good shape in the framework and think that in order to expedite the work we need to address the following topic and I think it will be good use of our time to do it in the Interim meeting. These are the topics as I see them. Please feel free to comment. Data model At the last Interim meeting in February Andy presented an initial data structure in http://www.ietf.org/proceedings/interim/2012/02/15/clue/slides/clue-5.doc . This is an XML schema that has the outline of the data but it is very basic and need more work. There was a discussion if the encoding group information can be described using SDP and http://tools.ietf.org/html/draft-romanow-clue-sdp-usage-01 is an attempt to describe the encoding groups in SDP. It was presented in IETF83 (Paris) but there was no real progress or discussion since then. CLUE transport. The group is still evaluating what is the right transport for the CLUE protocol. The major options are using a second MIME body in offer answer (similar to the approach taken in SIPREC http://tools.ietf.org/html/draft-ietf-siprec-protocol-03 ) or using RFC3264 offer answer to negotiate an end to end channel that will carry the CLUE protocol (maybe something like BFCP). The draft http://tools.ietf.org/html/draft-wenger-clue-transport-02 was presented in IETF83 (Paris) but the issue is still open. Some other work on the topic is in http://tools.ietf.org/html/draft-cazeaux-clue-sip-signaling-01 which suggests using SDP with offer answer. http://tools.ietf.org/html/draft-hansen-clue-protocol-choices-evaluation-00 is trying to evaluate both transport options. The solution should take into account the call flow which is still an open issue. CLUE call flow The framework talks about 3 messages (consumer capabilities, provider advertisement and consumer configuration). There is an ongoing discussion if we need all three and how they fit with the offer answer exchange. The more general question is how many messages it take to establish a TP call. While the provider advertisement and consumer configuration are used to negotiate the media captures that will be used in the call it is not clear why we need the consumer capability. The justification for the consumer capabilities may be to allow the provider to advertise the relevant capture scene entries, for example a 3 camera system sending an advertisement to a 2 screen system may offer only capture scene entries relevant to two screens system. This subject is relevant to the CLUE transport work which will include the call flows. Mapping of CLUE media captures to RTP payload (SSRC and payload type number) The media captures provide information about constrains of the streams and the spatial relation between them. The streams themselves are described in SIP using SDP and they can be identified by their SSRC numbers. The mapping between these two is important to allow the receiver of the RTP stream to know where to display them. http://tools.ietf.org/html/draft-even-clue-rtp-mapping-01 is trying to propose a solution but need more work. There is a similar requirement in RTCweb and http://tools.ietf.org/html/draft-alvestrand-rtcweb-msid-01 tries a different approach. In IETF83 the author of the RTCweb draft was asked to look at using grouping and SSRC for this mapping. This may require new attribute to the SSRC SDP attribute. RTP usage in CLUE This topic is about multiplexing RTP streams in CLUE. In RTCweb the direction is to multiple the audio and video in one UDP session and work is now in progress in AVTcore and MMUSIC to address this requirement. In CLUE it is desirable to multiplex all the video streams in one UDP connection. http://tools.ietf.org/html/draft-lennox-clue-rtp-usage-03 present and recommends the RTP multiplexing mechanism. Thanks Roni ------=_NextPart_000_0004_01CD3817.3E001B10 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

Hi = Guys,

I think that we are in a good = shape in the framework and think that in order to expedite the work we = need to address the following topic and I think it will be good use of = our time to do it in the Interim meeting.

These are the topics as I see them. Please feel free = to comment.

 

Data model

At the last Interim meeting in February Andy presented = an initial data structure in http://www.ietf.org/proceedings/interim/2012/02/15/clue/slides/= clue-5.doc . This is an XML schema that has the outline of the data = but it is very basic and need more work. There was a discussion if the = encoding group information can be described using SDP and http:= //tools.ietf.org/html/draft-romanow-clue-sdp-usage-01 is an attempt = to describe the encoding groups in SDP. It was presented in IETF83 = (Paris) but there was no real progress or discussion since = then.

CLUE transport.

The group is still evaluating what is the right = transport for the CLUE protocol. The major options are using a second = MIME body in offer answer (similar to the approach taken in SIPREC http://= tools.ietf.org/html/draft-ietf-siprec-protocol-03 ) or using RFC3264 = offer answer to negotiate an end to end channel that will carry the CLUE = protocol (maybe something like BFCP). The draft http://tools.ietf.org/html/draft-wenger-clue-tr= ansport-02 was presented in IETF83 (Paris) but the issue is still = open.

Some other work on the topic is = in h= ttp://tools.ietf.org/html/draft-cazeaux-clue-sip-signaling-01 which = suggests using SDP with offer answer.

http://tools.ietf.org/html/draft-hansen-clue-protocol-choices= -evaluation-00 is trying to evaluate both transport options. =

The solution should take into = account the call flow which is still an open = issue.

CLUE call flow

The framework talks about 3 messages (consumer = capabilities, provider advertisement and consumer configuration). There = is an ongoing discussion if we need all three and how they fit with the = offer answer exchange. The more general question is how many messages it = take to establish a TP call. While the provider advertisement and = consumer configuration are used to negotiate the media captures that = will be used in the call it is not clear why we need the consumer = capability. The justification for the consumer capabilities may be to = allow the provider to advertise the relevant capture scene entries, for = example a 3 camera system sending an advertisement to a 2 screen system = may offer only capture scene entries relevant to two screens = system.

This subject is relevant to = the CLUE transport work which will include the call = flows.

 

Mapping of CLUE media = captures to RTP payload (SSRC and payload type number)

The media captures provide information about = constrains of the streams and the spatial relation between them. The = streams themselves are described in SIP using SDP and they can be = identified by their SSRC numbers. The mapping between these two is = important to allow the receiver of the RTP stream to know where to = display them.  http:/= /tools.ietf.org/html/draft-even-clue-rtp-mapping-01 is trying to = propose a solution but need more work. There is a similar requirement in = RTCweb and http:= //tools.ietf.org/html/draft-alvestrand-rtcweb-msid-01 tries a = different approach. In IETF83 the author of the RTCweb draft was asked = to look at using grouping and SSRC for this mapping. This may require = new attribute to the SSRC SDP attribute.

 

RTP usage in = CLUE

This topic is about = multiplexing RTP streams in CLUE. In RTCweb the direction is to multiple = the audio and video in one UDP session and work is now in progress in = AVTcore and MMUSIC to address this requirement. In CLUE it is desirable = to multiplex all the video streams in one UDP connection.  http:/= /tools.ietf.org/html/draft-lennox-clue-rtp-usage-03 present and = recommends the RTP multiplexing mechanism.

Thanks

Roni

 

------=_NextPart_000_0004_01CD3817.3E001B10-- From Mark.Duckworth@polycom.com Tue May 22 04:09:30 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E59E121F85D0 for ; Tue, 22 May 2012 04:09:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SeMs-fJkTW4N for ; Tue, 22 May 2012 04:09:30 -0700 (PDT) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 90B0821F85CF for ; Tue, 22 May 2012 04:09:29 -0700 (PDT) Received: from Crpmboxprd01.polycom.com ([fe80::ad68:5a0:c919:66b6]) by crpehubprd02.polycom.com ([fe80::5efe:10.236.0.154%12]) with mapi; Tue, 22 May 2012 04:09:28 -0700 From: "Duckworth, Mark" To: Stephan Wenger , "clue@ietf.org" Date: Tue, 22 May 2012 04:09:28 -0700 Thread-Topic: Ticket #9 - axis of capture description Thread-Index: Ac03nw5TzZOcf7sESlmBc00DHwCTSf//k/4A//69b3A= Message-ID: <44C6B6B2D0CF424AA90B6055548D7A6102FD836E0E@CRPMBOXPRD01.polycom.com> References: <44C6B6B2D0CF424AA90B6055548D7A6102FD836DA5@CRPMBOXPRD01.polycom.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [clue] Ticket #9 - axis of capture description X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 22 May 2012 11:09:31 -0000 Hi Stephan, that's good, thanks. Mark > -----Original Message----- > From: Stephan Wenger [mailto:stewe@stewe.org] > Sent: Monday, May 21, 2012 6:48 PM > To: Duckworth, Mark; clue@ietf.org > Subject: Re: Ticket #9 - axis of capture description >=20 > Uh. Yes and No to your questions. I will have a text proposal ready by = the > interim, or shortly before. And perhaps also a slide deck. Good? > Stephan >=20 >=20 > On 5.21.2012 15:14 , "Duckworth, Mark" > wrote: >=20 > >Hi Stephan, > >Do you want to discuss your proposal for describing the "capture axis" > >at the upcoming interim meeting, as part of a framework discussion? Do > >you have any more details yet? > > > >Mark > > > >> -----Original Message----- > >> From: Stephan Wenger [mailto:stewe@stewe.org] > >> Sent: Tuesday, March 06, 2012 7:35 PM > >> To: Paul Kyzivat; Duckworth, Mark > >> Cc: clue@ietf.org > >> Subject: Re: [clue] Language re capture axis > >> > >> With the understanding that "out of this version" means "out of this > >>interation of the I-D", I'm fine. I still want this in the published > >>RFC. > >> Same goes for (de)composition info. > >> I will propose text as soon as I find the cycles (not before the > >>Paris I-D deadline). > >> > >> Stephan > >> > >> > >> On 3.6.2012 14:51 , "Paul Kyzivat" wrote: > >> > >> >On 3/5/12 1:29 PM, Duckworth, Mark wrote: > >> >> As editor, it seems I should leave this out of the next version. > >>Okay? > >> > > >> >I'm ok with leaving any mention of it out, assuming those who were > >> >concerned about it (Stephan) are ok with that. > >> > > >> > Paul > >> > > >> >> Otherwise, I would appreciate having interested parties propose > >> >>new text to discuss on the mailing list, considering Paul's desire > >> >>to have more specific text than what we have previously discussed. > >> >> > >> >> Thanks, > >> >> Mark > >> >> > >> >>> -----Original Message----- > >> >>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > >> >>> Sent: Thursday, March 01, 2012 4:53 PM > >> >>> To: Duckworth, Mark > >> >>> Cc: clue@ietf.org > >> >>> Subject: Re: [clue] Language re capture axis > >> >>> > >> >>> On 2/29/12 11:14 AM, Duckworth, Mark wrote: > >> >>>> Paul and Stephan, > >> >>>> > >> >>>> Personally, I'd rather just leave it out altogether because I > >> >>>>think it doesn't > >> >>> add anything that needs to be standardized. But Stephan thought > >> >>>it was important, so I was trying to find a way to say it in an > >> >>>"accurate enough" way. > >> >>> > >> >>> If there is no widespread interest in having this, and those who > >> >>>have asked about it are happy without, then I'm fine with leaving > >> >>>it out. > >> >>> > >> >>> If it is to be mentioned, with the idea that the recipient might > >> >>>use it for something, then I think it should be made clear how it > >> >>>can be determined. > >> >>> > >> >>> Thanks, > >> >>> Paul > >> >>> > >> >>>> Mark > >> >>>> > >> >>>>> -----Original Message----- > >> >>>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On > >> >>>>> Behalf Of Paul Kyzivat > >> >>>>> Sent: Wednesday, February 29, 2012 10:56 AM > >> >>>>> To: clue@ietf.org > >> >>>>> Subject: Re: [clue] Language re capture axis > >> >>>>> > >> >>>>> On 2/29/12 10:10 AM, Duckworth, Mark wrote: > >> >>>>>> Hi Stephan, > >> >>>>>> > >> >>>>>> I agree in principle with your suggestion, but I think your > >> >>>>>> suggested text is not mathematically accurate. I think the > >> >>>>>> axis of capture doesn't go to the center of the area of > >> >>>>>> capture. For example, if the camera is pointed at the area of > >> >>>>>> capture at an angle, the center point of the area would not > >> >>>>>> line up with the center point of the camera's field of view > >> >>>>>> (which defines the > >>axis). > >> >>>>>> > >> >>>>>> So rather than try to get into the mathematical details, how > >> >>>>>>about > >> >>>>>>this: > >> >>>>>> > >> >>>>>> "Note that, for the purpose of receiver-side geometric > >> >>>>>> correction, it can be assumed that the axis of capture of > >> >>>>>> directional capture devices (cameras, directional microphones > >> >>>>>> etc.) can be calculated from the coordinates of the point of > >>capture > >> and area of capture." > >> >>>>> > >> >>>>> IMO this is dangerously vague. Presumably there is a real axis > >> >>>>>of capture. > >> >>>>> Hopefully there is a well defined algorithm for deriving the > >> >>>>>axis from the available data, so that the recipient will > >> >>>>>determine the actual axis. If so, then it should be specified or > >> >>>>>referenced from some source. Otherwise we run the risk that not > >> >>>>>all will correctly derive > >> >>> the axis. > >> >>>>> > >> >>>>> Thanks, > >> >>>>> Paul > >> >>>>> > >> >>>>>> Mark > >> >>>>>> > >> >>>>>> *From:*clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] > >> >>>>>> *On Behalf Of *Stephan Wenger > >> >>>>>> *Sent:* Wednesday, February 15, 2012 11:04 AM > >> >>>>>> *To:* clue@ietf.org > >> >>>>>> *Subject:* [clue] Language re capture axis > >> >>>>>> > >> >>>>>> Hi, > >> >>>>>> > >> >>>>>> The issue I mentioned in the meeting is that nowhere in the > >> >>>>>> framework (as far as I recall) the axis of capture of a video > >> >>>>>> capture (or directional audio capture-anything that is not > >> >>>>>> omnidirectional) is undefined. Without that axis being > >> >>>>>> defined, receiver-side geometric correction is not possible. > >> >>>>>> > >> >>>>>> The issue could be solved in two ways: include attributes, per > >> >>>>>> capture, indicating angle of capture in 3D space (relative to > >> >>>>>> what???), or by making the bold assumption that the > >> >>>>>> coordinates defining area of capture plus capture point define > >> >>>>>> the axis of capture. I suggest the latter as it is easy to > >> >>>>>> implement and (I > >> >>>>>> believe) > >> >>>>> practical. > >> >>>>>> > >> >>>>>> The language could be something like: > >> >>>>>> > >> >>>>>> " > >> >>>>>> > >> >>>>>> Note that, for the purpose of receiver-side geometric > >> >>>>>> correction, it can be assumed that the axis of capture of > >> >>>>>> directional capture devices (cameras, directional microphones > >> >>>>>> etc.) is the line from the capture point to the center of the p= lane > of capture. > >> >>>>>> > >> >>>>>> " > >> >>>>>> > >> >>>>>> Stephan > >> >>>>>> > >> >>>>>> > >> >>>>>> > >> >>>>>> _______________________________________________ > >> >>>>>> clue mailing list > >> >>>>>> clue@ietf.org > >> >>>>>> https://www.ietf.org/mailman/listinfo/clue > >> >>>>> > >> >>>>> _______________________________________________ > >> >>>>> clue mailing list > >> >>>>> clue@ietf.org > >> >>>>> https://www.ietf.org/mailman/listinfo/clue > >> >>>> > >> >> > >> >> > >> > > >> >_______________________________________________ > >> >clue mailing list > >> >clue@ietf.org > >> >https://www.ietf.org/mailman/listinfo/clue > >> > > >> > > > > >=20 From marshall.eubanks@gmail.com Tue May 22 06:26:07 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D88321F8619 for ; Tue, 22 May 2012 06:26:07 -0700 (PDT) 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=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id juQ9Z3g5xHkG for ; Tue, 22 May 2012 06:26:07 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 71DBD21F85FC for ; Tue, 22 May 2012 06:26:06 -0700 (PDT) Received: by lagv3 with SMTP id v3so4947608lag.31 for ; Tue, 22 May 2012 06:26:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=67nkx6dd/yT9IL3yoDadwCD4AvwqiwU9P+dNQrranB0=; b=wPzR7+EasFkHN5DyJZ+YKD+I/v7+J5yWcgVwZ5RdN+RbwjbgLUDkHSaRt0lsK5wmu3 cOVcTHAOALA9LWPoQnwXvBCFbigf3ZNTONCVKw4ve5DLwLy387L2/m571uq9WXc1w/iF eg5xX1rQpBF+QdmSpbjGXGonCEKpYQeWGfLuUXGB2kKdP6iYKg+132aVQlPNZrGITBjS M4/stu2AEqVKq1oUi7XnY2KVYc5XUuSENKOX90bCKxvpGizcw1tpG/EH34jOH2dVQYXV q9NbgaL/+Fuk00MIj162wDzvmZY32dAMkhpr56T+CbRRqi2w4fEzMQkvF18pCTs7up00 Ox0A== MIME-Version: 1.0 Received: by 10.152.104.171 with SMTP id gf11mr23288216lab.5.1337693165319; Tue, 22 May 2012 06:26:05 -0700 (PDT) Received: by 10.112.56.13 with HTTP; Tue, 22 May 2012 06:26:05 -0700 (PDT) In-Reply-To: <4fbb5e2f.b448b40a.38d1.17da@mx.google.com> References: <4fbb5e2f.b448b40a.38d1.17da@mx.google.com> Date: Tue, 22 May 2012 09:26:05 -0400 Message-ID: From: Marshall Eubanks To: Roni Even Content-Type: text/plain; charset=ISO-8859-1 Cc: clue@ietf.org Subject: Re: [clue] My view if CLUE status and topics for Interim meeting X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 22 May 2012 13:26:07 -0000 On Tue, May 22, 2012 at 5:34 AM, Roni Even wrote: > > > Hi Guys, > > I think that we are in a good shape in the framework and think that in order > to expedite the work we need to address the following topic and I think it > will be good use of our time to do it in the Interim meeting. > > These are the topics as I see them. Please feel free to comment. > > > > Data model > > At the last Interim meeting in February Andy presented an initial data > structure in > http://www.ietf.org/proceedings/interim/2012/02/15/clue/slides/clue-5.doc . > This is an XML schema that has the outline of the data but it is very basic > and need more work. There was a discussion if the encoding group information > can be described using SDP and > http://tools.ietf.org/html/draft-romanow-clue-sdp-usage-01 is an attempt to > describe the encoding groups in SDP. It was presented in IETF83 (Paris) but > there was no real progress or discussion since then. > > CLUE transport. > > The group is still evaluating what is the right transport for the CLUE > protocol. The major options are using a second MIME body in offer answer > (similar to the approach taken in SIPREC > http://tools.ietf.org/html/draft-ietf-siprec-protocol-03 ) or using RFC3264 > offer answer to negotiate an end to end channel that will carry the CLUE > protocol (maybe something like BFCP). The draft > http://tools.ietf.org/html/draft-wenger-clue-transport-02 was presented in > IETF83 (Paris) but the issue is still open. > Given that rtcweb has firmly decided to use SRTP, and only SRTP, for transport, shouldn't SRTP be added to the mix here ? Regards Marshall > Some other work on the topic is in > http://tools.ietf.org/html/draft-cazeaux-clue-sip-signaling-01 which > suggests using SDP with offer answer. > > http://tools.ietf.org/html/draft-hansen-clue-protocol-choices-evaluation-00 > is trying to evaluate both transport options. > > The solution should take into account the call flow which is still an open > issue. > > CLUE call flow > > The framework talks about 3 messages (consumer capabilities, provider > advertisement and consumer configuration). There is an ongoing discussion if > we need all three and how they fit with the offer answer exchange. The more > general question is how many messages it take to establish a TP call. While > the provider advertisement and consumer configuration are used to negotiate > the media captures that will be used in the call it is not clear why we need > the consumer capability. The justification for the consumer capabilities may > be to allow the provider to advertise the relevant capture scene entries, > for example a 3 camera system sending an advertisement to a 2 screen system > may offer only capture scene entries relevant to two screens system. > > This subject is relevant to the CLUE transport work which will include the > call flows. > > > > Mapping of CLUE media captures to RTP payload (SSRC and payload type number) > > The media captures provide information about constrains of the streams and > the spatial relation between them. The streams themselves are described in > SIP using SDP and they can be identified by their SSRC numbers. The mapping > between these two is important to allow the receiver of the RTP stream to > know where to display them. > http://tools.ietf.org/html/draft-even-clue-rtp-mapping-01 is trying to > propose a solution but need more work. There is a similar requirement in > RTCweb and http://tools.ietf.org/html/draft-alvestrand-rtcweb-msid-01 tries > a different approach. In IETF83 the author of the RTCweb draft was asked to > look at using grouping and SSRC for this mapping. This may require new > attribute to the SSRC SDP attribute. > > > > RTP usage in CLUE > > This topic is about multiplexing RTP streams in CLUE. In RTCweb the > direction is to multiple the audio and video in one UDP session and work is > now in progress in AVTcore and MMUSIC to address this requirement. In CLUE > it is desirable to multiplex all the video streams in one UDP connection. > http://tools.ietf.org/html/draft-lennox-clue-rtp-usage-03 present and > recommends the RTP multiplexing mechanism. > > Thanks > > Roni > > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From espeberg@cisco.com Tue May 22 06:37:29 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C920D21F85EA for ; Tue, 22 May 2012 06:37:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TDGGfpfjXwsI for ; Tue, 22 May 2012 06:37:29 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 426C121F85D6 for ; Tue, 22 May 2012 06:37:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=espeberg@cisco.com; l=5344; q=dns/txt; s=iport; t=1337693848; x=1338903448; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=rf6HO9vFxOkgNbQCOiPtmBydA9eGqNajUTpSFkzk/8M=; b=aVycxr3suj4L3yCwUPRfr6Ja2G+3th+iMrOR0dtPr/QVeqRYglvOP0Hj +I9VWUSoFmmGUPq3txGf2J3a34fyb2l++c6YmX8tc1qTbRtBeHTOKN9+J U0WpdL/zkqSyyT81GCVWTbURULRVwDbtyp/hDO2eYfSZjdvcSuvGYb36J M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAGt+u0+Q/khL/2dsb2JhbABDtBKBB4IVAQEBAwEBAQEPAR0KNAQHBQcEAgEIEQQBAQEKBgUSAQYBIAYfCQgBAQQBEggBEgeHXgMGBQuZPZYzDYlSihpughKCSGIDliqJaIMVgWSCaw X-IronPort-AV: E=Sophos;i="4.75,637,1330905600"; d="scan'208";a="73477018" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 22 May 2012 13:37:26 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q4MDbR0K029672; Tue, 22 May 2012 13:37:27 GMT Received: from xmb-ams-214.cisco.com ([144.254.75.25]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 22 May 2012 15:37:26 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 22 May 2012 15:37:24 +0200 Message-ID: <92DF9533227FC14F946C7321074B8C9E0133072E@XMB-AMS-214.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] My view if CLUE status and topics for Interim meeting Thread-Index: Ac04HnX2OmmT2sXWQW2mviAd88z/aQAAPQVg References: <4fbb5e2f.b448b40a.38d1.17da@mx.google.com> From: "Espen Berger (espeberg)" To: "Marshall Eubanks" , "Roni Even" X-OriginalArrivalTime: 22 May 2012 13:37:26.0608 (UTC) FILETIME=[06B27500:01CD3820] Cc: clue@ietf.org Subject: Re: [clue] My view if CLUE status and topics for Interim meeting X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 22 May 2012 13:37:30 -0000 Marshal, did you mean sctp?=20 http://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-00 For CLUE message transport I think a reliable transport channel is a good option. Especially if it's used by other IETF protocols that also benefits from reliable and in-order message delivery.=20 As I remember SRTP is used for media encryption.=20 Cheers=20 -Espen =20 -----Original Message----- From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Marshall Eubanks Sent: 22. mai 2012 06:26 To: Roni Even Cc: clue@ietf.org Subject: Re: [clue] My view if CLUE status and topics for Interim meeting On Tue, May 22, 2012 at 5:34 AM, Roni Even wrote: > > > Hi Guys, > > I think that we are in a good shape in the framework and think that in > order to expedite the work we need to address the following topic and=20 > I think it will be good use of our time to do it in the Interim meeting. > > These are the topics as I see them. Please feel free to comment. > > > > Data model > > At the last Interim meeting in February Andy presented an initial data > structure in=20 > http://www.ietf.org/proceedings/interim/2012/02/15/clue/slides/clue-5.do c . > This is an XML schema that has the outline of the data but it is very=20 > basic and need more work. There was a discussion if the encoding group > information can be described using SDP and > http://tools.ietf.org/html/draft-romanow-clue-sdp-usage-01 is an=20 > attempt to describe the encoding groups in SDP. It was presented in=20 > IETF83 (Paris) but there was no real progress or discussion since then. > > CLUE transport. > > The group is still evaluating what is the right transport for the CLUE > protocol. The major options are using a second MIME body in offer=20 > answer (similar to the approach taken in SIPREC > http://tools.ietf.org/html/draft-ietf-siprec-protocol-03 ) or using=20 > RFC3264 offer answer to negotiate an end to end channel that will=20 > carry the CLUE protocol (maybe something like BFCP). The draft > http://tools.ietf.org/html/draft-wenger-clue-transport-02 was=20 > presented in > IETF83 (Paris) but the issue is still open. > Given that rtcweb has firmly decided to use SRTP, and only SRTP, for transport, shouldn't SRTP be added to the mix here ? Regards Marshall > Some other work on the topic is in > http://tools.ietf.org/html/draft-cazeaux-clue-sip-signaling-01 which=20 > suggests using SDP with offer answer. > > http://tools.ietf.org/html/draft-hansen-clue-protocol-choices-evaluati > on-00 is trying to evaluate both transport options. > > The solution should take into account the call flow which is still an=20 > open issue. > > CLUE call flow > > The framework talks about 3 messages (consumer capabilities, provider=20 > advertisement and consumer configuration). There is an ongoing=20 > discussion if we need all three and how they fit with the offer answer > exchange. The more general question is how many messages it take to=20 > establish a TP call. While the provider advertisement and consumer=20 > configuration are used to negotiate the media captures that will be=20 > used in the call it is not clear why we need the consumer capability.=20 > The justification for the consumer capabilities may be to allow the=20 > provider to advertise the relevant capture scene entries, for example=20 > a 3 camera system sending an advertisement to a 2 screen system may offer only capture scene entries relevant to two screens system. > > This subject is relevant to the CLUE transport work which will include > the call flows. > > > > Mapping of CLUE media captures to RTP payload (SSRC and payload type=20 > number) > > The media captures provide information about constrains of the streams > and the spatial relation between them. The streams themselves are=20 > described in SIP using SDP and they can be identified by their SSRC=20 > numbers. The mapping between these two is important to allow the=20 > receiver of the RTP stream to know where to display them. > http://tools.ietf.org/html/draft-even-clue-rtp-mapping-01 is trying to > propose a solution but need more work. There is a similar requirement=20 > in RTCweb and=20 > http://tools.ietf.org/html/draft-alvestrand-rtcweb-msid-01 tries a=20 > different approach. In IETF83 the author of the RTCweb draft was asked > to look at using grouping and SSRC for this mapping. This may require new attribute to the SSRC SDP attribute. > > > > RTP usage in CLUE > > This topic is about multiplexing RTP streams in CLUE. In RTCweb the=20 > direction is to multiple the audio and video in one UDP session and=20 > work is now in progress in AVTcore and MMUSIC to address this=20 > requirement. In CLUE it is desirable to multiplex all the video streams in one UDP connection. > http://tools.ietf.org/html/draft-lennox-clue-rtp-usage-03 present and=20 > recommends the RTP multiplexing mechanism. > > Thanks > > Roni > > > > > _______________________________________________ > 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 From marshall.eubanks@gmail.com Tue May 22 07:16:58 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D5C821F84FB for ; Tue, 22 May 2012 07:16:58 -0700 (PDT) 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=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zmh3IOd6Q+1R for ; Tue, 22 May 2012 07:16:57 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8DF9021F847D for ; Tue, 22 May 2012 07:16:56 -0700 (PDT) Received: by lagv3 with SMTP id v3so4998219lag.31 for ; Tue, 22 May 2012 07:16:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=KdvG30G+EUpHcB08QtEuCrLPl1zUv2dlPWWYvNYMwGA=; b=OmsfnfR5QjXhM35it3NCG0nD5lcYwVZZ3pK3m6XnkFWWqhN530FnvwDZ9psAYfrl2x GGQdOmy5s9ujOjJ30ZZVkwstWEfuabrqvGhVUQgfF18YTQAYAjXt1q5ynC3Ssii5xk4T MhEIWGqT7fsCGocdKDqqyYGFyUwZ63bCluPf3HQIxts80YRaR5cN+CMQOxu1nbRkHCDU c8XsKMajmbamVd+VqkP5rWfxllurjoQ04s4xbzYIfocWa2FXkB1hmQt6la38qteMrf42 AkGJFPM8Yu7iZ5jUHLbpKcj41HcAAMi4uzKtrgBOuqTL0Tp15iYed3Wf9LEVq0plXSwR ub9A== MIME-Version: 1.0 Received: by 10.112.36.195 with SMTP id s3mr10336709lbj.42.1337696215480; Tue, 22 May 2012 07:16:55 -0700 (PDT) Received: by 10.112.56.13 with HTTP; Tue, 22 May 2012 07:16:55 -0700 (PDT) In-Reply-To: <92DF9533227FC14F946C7321074B8C9E0133072E@XMB-AMS-214.cisco.com> References: <4fbb5e2f.b448b40a.38d1.17da@mx.google.com> <92DF9533227FC14F946C7321074B8C9E0133072E@XMB-AMS-214.cisco.com> Date: Tue, 22 May 2012 10:16:55 -0400 Message-ID: From: Marshall Eubanks To: "Espen Berger (espeberg)" Content-Type: text/plain; charset=ISO-8859-1 Cc: clue@ietf.org Subject: Re: [clue] My view if CLUE status and topics for Interim meeting X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 22 May 2012 14:16:58 -0000 On Tue, May 22, 2012 at 9:37 AM, Espen Berger (espeberg) wrote: > Marshal, did you mean sctp? > http://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-00 No, I did not, I meant SRTP. http://www.ietf.org/mail-archive/web/rtcweb/current/msg04264.html (I was in the rough on this one.) http://www.ietf.org/rfc/rfc3711.txt Regards Marshall > > For CLUE message transport I think a reliable transport channel is a > good option. Especially if it's used by other IETF protocols that also > benefits from reliable and in-order message delivery. > > As I remember SRTP is used for media encryption. > > Cheers > > -Espen > > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Marshall Eubanks > Sent: 22. mai 2012 06:26 > To: Roni Even > Cc: clue@ietf.org > Subject: Re: [clue] My view if CLUE status and topics for Interim > meeting > > On Tue, May 22, 2012 at 5:34 AM, Roni Even > wrote: >> >> >> Hi Guys, >> >> I think that we are in a good shape in the framework and think that in > >> order to expedite the work we need to address the following topic and >> I think it will be good use of our time to do it in the Interim > meeting. >> >> These are the topics as I see them. Please feel free to comment. >> >> >> >> Data model >> >> At the last Interim meeting in February Andy presented an initial data > >> structure in >> > http://www.ietf.org/proceedings/interim/2012/02/15/clue/slides/clue-5.do > c . >> This is an XML schema that has the outline of the data but it is very >> basic and need more work. There was a discussion if the encoding group > >> information can be described using SDP and >> http://tools.ietf.org/html/draft-romanow-clue-sdp-usage-01 is an >> attempt to describe the encoding groups in SDP. It was presented in >> IETF83 (Paris) but there was no real progress or discussion since > then. >> >> CLUE transport. >> >> The group is still evaluating what is the right transport for the CLUE > >> protocol. The major options are using a second MIME body in offer >> answer (similar to the approach taken in SIPREC >> http://tools.ietf.org/html/draft-ietf-siprec-protocol-03 ) or using >> RFC3264 offer answer to negotiate an end to end channel that will >> carry the CLUE protocol (maybe something like BFCP). The draft >> http://tools.ietf.org/html/draft-wenger-clue-transport-02 was >> presented in >> IETF83 (Paris) but the issue is still open. >> > > Given that rtcweb has firmly decided to use SRTP, and only SRTP, for > transport, shouldn't SRTP be added to the mix here ? > > Regards > Marshall > > >> Some other work on the topic is in >> http://tools.ietf.org/html/draft-cazeaux-clue-sip-signaling-01 which >> suggests using SDP with offer answer. >> >> http://tools.ietf.org/html/draft-hansen-clue-protocol-choices-evaluati >> on-00 is trying to evaluate both transport options. >> >> The solution should take into account the call flow which is still an >> open issue. >> >> CLUE call flow >> >> The framework talks about 3 messages (consumer capabilities, provider >> advertisement and consumer configuration). There is an ongoing >> discussion if we need all three and how they fit with the offer answer > >> exchange. The more general question is how many messages it take to >> establish a TP call. While the provider advertisement and consumer >> configuration are used to negotiate the media captures that will be >> used in the call it is not clear why we need the consumer capability. >> The justification for the consumer capabilities may be to allow the >> provider to advertise the relevant capture scene entries, for example >> a 3 camera system sending an advertisement to a 2 screen system may > offer only capture scene entries relevant to two screens system. >> >> This subject is relevant to the CLUE transport work which will include > >> the call flows. >> >> >> >> Mapping of CLUE media captures to RTP payload (SSRC and payload type >> number) >> >> The media captures provide information about constrains of the streams > >> and the spatial relation between them. The streams themselves are >> described in SIP using SDP and they can be identified by their SSRC >> numbers. The mapping between these two is important to allow the >> receiver of the RTP stream to know where to display them. >> http://tools.ietf.org/html/draft-even-clue-rtp-mapping-01 is trying to > >> propose a solution but need more work. There is a similar requirement >> in RTCweb and >> http://tools.ietf.org/html/draft-alvestrand-rtcweb-msid-01 tries a >> different approach. In IETF83 the author of the RTCweb draft was asked > >> to look at using grouping and SSRC for this mapping. This may require > new attribute to the SSRC SDP attribute. >> >> >> >> RTP usage in CLUE >> >> This topic is about multiplexing RTP streams in CLUE. In RTCweb the >> direction is to multiple the audio and video in one UDP session and >> work is now in progress in AVTcore and MMUSIC to address this >> requirement. In CLUE it is desirable to multiplex all the video > streams in one UDP connection. >> http://tools.ietf.org/html/draft-lennox-clue-rtp-usage-03 present and >> recommends the RTP multiplexing mechanism. >> >> Thanks >> >> Roni >> >> >> >> >> _______________________________________________ >> 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 From ron.even.tlv@gmail.com Tue May 22 08:05:56 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5469021F8610 for ; Tue, 22 May 2012 08:05:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.243 X-Spam-Level: X-Spam-Status: No, score=-3.243 tagged_above=-999 required=5 tests=[AWL=0.356, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ydX9RaWKxxQ6 for ; Tue, 22 May 2012 08:05:55 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 00BC321F846C for ; Tue, 22 May 2012 08:05:54 -0700 (PDT) Received: by bkty8 with SMTP id y8so6118541bkt.31 for ; Tue, 22 May 2012 08:05:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; 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; bh=yC9C0kukaoLzZk2EC3qPEOBsQHQb9b1LX4xOsj3+gAQ=; b=g4LxTNNj9LW6/23SyH5zjVCCSUWGAKVi7cu/OxCnvw/yEk4yfM6lZebRKtHrhDIm3p iRdVcn/sd5B8kkkiLqdZbbOs2blTVK2dws7+BWvvYtOAsSc/3k63DzU97byo5m26n8FR 3+ApLTj+6oKTkGT06K69G+xfInEwcCTRpIu0kPRjyqKkopfj5T36Zmo5SJtNNqkDfCQ2 rLBkfcbwMstAOTNruxN0sipP6m7cdSrE35aEcJ968nrkrIfekWkWBQbfhYESAbgSOp9F 20dY8iDhdOJjTm+ypN25g2bdNwUQDn2eTtshvwxgE4WW4PA65JSCVoOgF+1l7+cbg2j5 uxZg== Received: by 10.204.152.199 with SMTP id h7mr10248161bkw.39.1337699153800; Tue, 22 May 2012 08:05:53 -0700 (PDT) Received: from windows8d787f9 (bzq-79-177-198-116.red.bezeqint.net. [79.177.198.116]) by mx.google.com with ESMTPS id x23sm32754328bkw.12.2012.05.22.08.05.50 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 22 May 2012 08:05:51 -0700 (PDT) From: "Roni Even" To: "'Marshall Eubanks'" References: <4fbb5e2f.b448b40a.38d1.17da@mx.google.com> In-Reply-To: Date: Tue, 22 May 2012 18:03:35 +0300 Message-ID: <4fbbab4f.979ccc0a.68d2.ffffa92f@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: Ac04HnBtFlDmSTy0T8at62L9nUGvFwADVSYA Content-Language: en-us Cc: clue@ietf.org Subject: Re: [clue] My view if CLUE status and topics for Interim meeting X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 22 May 2012 15:05:56 -0000 Marshal, We are talking about how to transport the CLUE message and not the media in this item. Maybe SRTP should be part of RTP usage in CLUE and I can agree that it will make sense to discuss the issue of key exchange in SRTP for CLUE Roni > -----Original Message----- > From: Marshall Eubanks [mailto:marshall.eubanks@gmail.com] > Sent: Tuesday, May 22, 2012 4:26 PM > To: Roni Even > Cc: clue@ietf.org > Subject: Re: [clue] My view if CLUE status and topics for Interim > meeting > > On Tue, May 22, 2012 at 5:34 AM, Roni Even > wrote: > > > > > > Hi Guys, > > > > I think that we are in a good shape in the framework and think that > in > > order to expedite the work we need to address the following topic and > > I think it will be good use of our time to do it in the Interim > meeting. > > > > These are the topics as I see them. Please feel free to comment. > > > > > > > > Data model > > > > At the last Interim meeting in February Andy presented an initial > data > > structure in > > http://www.ietf.org/proceedings/interim/2012/02/15/clue/slides/clue- > 5.doc . > > This is an XML schema that has the outline of the data but it is very > > basic and need more work. There was a discussion if the encoding > group > > information can be described using SDP and > > http://tools.ietf.org/html/draft-romanow-clue-sdp-usage-01 is an > > attempt to describe the encoding groups in SDP. It was presented in > > IETF83 (Paris) but there was no real progress or discussion since > then. > > > > CLUE transport. > > > > The group is still evaluating what is the right transport for the > CLUE > > protocol. The major options are using a second MIME body in offer > > answer (similar to the approach taken in SIPREC > > http://tools.ietf.org/html/draft-ietf-siprec-protocol-03 ) or using > > RFC3264 offer answer to negotiate an end to end channel that will > > carry the CLUE protocol (maybe something like BFCP). The draft > > http://tools.ietf.org/html/draft-wenger-clue-transport-02 was > > presented in > > IETF83 (Paris) but the issue is still open. > > > > Given that rtcweb has firmly decided to use SRTP, and only SRTP, for > transport, shouldn't SRTP be added to the mix here ? > > Regards > Marshall > > > > Some other work on the topic is in > > http://tools.ietf.org/html/draft-cazeaux-clue-sip-signaling-01 which > > suggests using SDP with offer answer. > > > > http://tools.ietf.org/html/draft-hansen-clue-protocol-choices- > evaluati > > on-00 is trying to evaluate both transport options. > > > > The solution should take into account the call flow which is still an > > open issue. > > > > CLUE call flow > > > > The framework talks about 3 messages (consumer capabilities, provider > > advertisement and consumer configuration). There is an ongoing > > discussion if we need all three and how they fit with the offer > answer > > exchange. The more general question is how many messages it take to > > establish a TP call. While the provider advertisement and consumer > > configuration are used to negotiate the media captures that will be > > used in the call it is not clear why we need the consumer capability. > > The justification for the consumer capabilities may be to allow the > > provider to advertise the relevant capture scene entries, for example > > a 3 camera system sending an advertisement to a 2 screen system may > offer only capture scene entries relevant to two screens system. > > > > This subject is relevant to the CLUE transport work which will > include > > the call flows. > > > > > > > > Mapping of CLUE media captures to RTP payload (SSRC and payload type > > number) > > > > The media captures provide information about constrains of the > streams > > and the spatial relation between them. The streams themselves are > > described in SIP using SDP and they can be identified by their SSRC > > numbers. The mapping between these two is important to allow the > > receiver of the RTP stream to know where to display them. > > http://tools.ietf.org/html/draft-even-clue-rtp-mapping-01 is trying > to > > propose a solution but need more work. There is a similar requirement > > in RTCweb and > > http://tools.ietf.org/html/draft-alvestrand-rtcweb-msid-01 tries a > > different approach. In IETF83 the author of the RTCweb draft was > asked > > to look at using grouping and SSRC for this mapping. This may require > new attribute to the SSRC SDP attribute. > > > > > > > > RTP usage in CLUE > > > > This topic is about multiplexing RTP streams in CLUE. In RTCweb the > > direction is to multiple the audio and video in one UDP session and > > work is now in progress in AVTcore and MMUSIC to address this > > requirement. In CLUE it is desirable to multiplex all the video > streams in one UDP connection. > > http://tools.ietf.org/html/draft-lennox-clue-rtp-usage-03 present and > > recommends the RTP multiplexing mechanism. > > > > Thanks > > > > Roni > > > > > > > > > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue > > From john@jlc.net Tue May 22 08:06:10 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C62D521F863D for ; Tue, 22 May 2012 08:06:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ho0ovSk8Fxmr for ; Tue, 22 May 2012 08:06:10 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 86C8A21F8622 for ; Tue, 22 May 2012 08:06:04 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 746A833C22; Tue, 22 May 2012 11:06:04 -0400 (EDT) Date: Tue, 22 May 2012 11:06:04 -0400 From: John Leslie To: Mary Barnes Message-ID: <20120522150604.GC2661@verdi> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Cc: CLUE Subject: [clue] Notes (May 22 @ 9am central) X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 22 May 2012 15:06:10 -0000 Mary Barnes wrote: > > 1) Criteria for CLUE signaling: > http://www.ietf.org/mail-archive/web/clue/current/msg01433.html [Note: > Christer cannot make this meeting, but we can still review and decide > whether we agree this is a good starting point] > > 2) Ticket #8: add description text to a capture scene > http://www.ietf.org/mail-archive/web/clue/current/msg01442.html > > 3) Ticket #8: capture scene coordinates and content attribute > http://www.ietf.org/mail-archive/web/clue/current/msg01446.html Present: John Leslie, Paul Kyzivat, Jonathan Lennox, Rob Hansen, Brian Baldino, Espen Berger, Mary Barnes. After meeting start Mark, Allyn, Roni. 1003 CTO Mary: sharing, browser, meeting tomorrow, Mark still not here... Mark joined, Allyn joining User9, Roni..., Christer not able to join Mary: first, signaling intermediaries need access? Roni: inaudible... it's also MCUs Jonathan: not the same thing, SBCs could be ordinary... Roni: if specific channel, would need to go through MCU anyway Jonathan: inherent in CLUE channel... everything that head-rails do Mary: agree with Jonathan, in nature of CLUE Roni: chicken-and-egg, anything CLUE-aware needs access, routing needs to go through intermediary Jonathan: question, whether this information is relevant to routing decision Roni: selecting... if you have multiple streams, controller in middle would like to route only some of them based on policy Mary: wouldn't policy in general cover that Roni: not just policy, may be some other things, we should decide whether part of signaling or separate channel Mary: reword to be more explicity Paul: may be of interest to all intermediaries... stuff pertinent to routing is different -- needed at time routing is being established Jonathan: use-case, trying to figure out which MCU... Paul: knowing bandwidth that will be required for this call Mary: hearing two separate things here Roni: suggestion I sent was expanding on that Mary: same channel is different question from who needs access Roni: makes sense only if you can see all this at the same time Mary: sub-bullets... three points that Roni made Roni: last one doesn't apply Jonathan: imagine session establishment... Mary: signaling vs. media... #4... separate out the two? Mary: #2 expected size... byte estimate Mary: #3 expected frequency, 3-tiers Mary: #4 whether sent during... Roni: establishing signaling vs. media Jonathan: what counts as "media"... other information... Mary: idea, be able to identify bits of information Roni: information, CLUE-call, then what else? establishing media comes last Paul: information for session-establishment, needed for CLUE-channel establishment... maximum bandwidth needed, during SIP-session establishment Mary: #5 whether information transport is delay-sensitive Paul: how sensitive-to-delay, what delay is tolerable Mary: we're defining characteristics needed Roni: various messages, delays for messages Mary: possible multiple ways Paul: some tunneled, etc Roni: not talking about anything except CLUE messages Mary: no, we're talking about what needs to be signaled Roni: delay-acceptable is for CLUE messages Mary: only in an abstract sense... Roni: whatever Mary: if we had data-model, we'd evaluate against criteria... Mary: #6 whether response is needed Roni: reliability? Jonathan: is there a handshake on action to take Paul: two things hiding here, if unreliable channel, may need to verify delivery Mary: that's later in #7 Mary: #8 needed by non-CLUE entity in order to participate Jonathan: what does non-CLUE entity mean? legacy SIP? one-camera-one-screen? Roni: should ask Christer what he meant Mary: #9 whether CLUE info is using one transport... needs to be carried with other elements? Roni: more-specific, media-capture, you can delete this one Mary: will send to list 1040 Mary: ticket #8 add description text to capture scene Mark: I thought we agreed to add human-readable, media-consumer can use that to let a human user make choice... related to ticket 8, though not a complete solution Allyn: something an individual system wants to add... what it wants to display to users, not a CLUE thing what they present to users, most people won't touch it, doesn't solve any of our problems, I see no reason to do this Mary: if optional, would it be a problem Allyn: my designs don't include unnecessary things Jonathan: how would you solve this problem Allyn: take what information you have, present it to user... some classification, not free text Paul: suppose you receive advertisement with two scenes, but you've only got one screen, how do you decide which one to display, what information would you use to decide Allyn: typically you have one for presentation... why isn't this enough? Paul: what if those aren't the labels Allyn: if you had "main" and "presentation", what more would you need? specifically, what is inadequate Paul: suppose I have three, two have main, third has presentation, I have only one screen and two "main"s Allyn: you want different kinds of "main"; that's fine, we'll add categories, what categories are missing, you don't have to answer now Roni: I agree with Allyn... it's not the text that distinguishes... if there's more than presentation and main, need to define characteristics Paul: I want to somehow distinguish... there's no requirement that the purpose must be different Roni: until we agree "what is a capture scene" we can't decide how to differentiate them... capture scene has its own coordinate space, presentation doesn't belong in main Rob: each person has separate capture scene, same purpose Roni: is each having no relation to the others, or does MCU relate them? Rob: in first case, capture scenes have the same purpose Paul: can still funnel through MCU, but it doesn't combine them Roni: don't think that's the model we want to address. John: might not multiple MCUs combine scenes differently Roni: typically an MCU will build a virtual room with no scaling John: sounds like a bad idea to lose the coordinate information Paul: you could create a synthetic coordiate space Roni: no you don't... the purpose is to adjust, if you do that, the mathematics will be wrong Allyn: not assigning a virtual coordinate space... not useful unless you're going to lay out one next to the other Mark: don't think we have a conclusion on description string Allyn: I don't like it, is anyone adamently in favor? Roni: the problem is that this isn't a ticket-8 issue -- human-readable text can't solve the ticket-8 issue, I don't object to human-reabable text, but we need a different proposal for ticket8 Mary: suggest we do consensus-call on-list Roni: must be kept separate from ticket-8 Mary: OK... we're out of time Adjourned 1101 -- John Leslie From mary.ietf.barnes@gmail.com Tue May 22 09:35:16 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FE6021F8624 for ; Tue, 22 May 2012 09:35:16 -0700 (PDT) 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=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jHY9d6LUbvtE for ; Tue, 22 May 2012 09:35:16 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id AE45B21F848F for ; Tue, 22 May 2012 09:35:15 -0700 (PDT) Received: by vcqp1 with SMTP id p1so738059vcq.31 for ; Tue, 22 May 2012 09:35:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=6TUsDaHGUjfvApdxbC1zvBQDbEfmgqi5N8pdPuD4YlA=; b=yYWLZ6+J5EEq9Fpv+shdv4DPYoFdKL/LLRL+CRtOU7GBXpHUA+bVvc12fbRjvCjLUx ANQIz/sN0Fy/cNaHiQCankM25GPAlVvqMbyNnO9XvTmKqRn2r9htEJdR03CtS0Mj3JpU xa2jOkE1Hkotq9xNkk+1q2TDDtTPlqdkfYy9U/F+pvEY55tnLcXY619CExd7BEeyC2zw cHmRLpiz/4vUTXk+2pTpD1pRR3e8+NMleFYjdtiCneDH6QsMKfyjvgA8UtEAsLNDAtfw ZvwYmz0obQCu5jzO45MM9+PHA5iUQJbfdCFhUDvYdGEYXBIpyTHz5ozeayR9A9Sg0KvX Cfaw== MIME-Version: 1.0 Received: by 10.220.221.139 with SMTP id ic11mr1229358vcb.74.1337704514432; Tue, 22 May 2012 09:35:14 -0700 (PDT) Received: by 10.52.22.143 with HTTP; Tue, 22 May 2012 09:35:14 -0700 (PDT) Date: Tue, 22 May 2012 11:35:14 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=14dae9cdca9165ae8604c0a29ad5 Subject: [clue] Add description text to a capture scene X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 22 May 2012 16:35:16 -0000 --14dae9cdca9165ae8604c0a29ad5 Content-Type: text/plain; charset=ISO-8859-1 Hi all, Per the design team meeting this morning, we are doing a consensus call on the question as to whether human readable text string should be added to the capture scene. Note that while this came up during discussion of Ticket #8 in a previous meeting, it does not impact the state of Ticket #8 which remains open: http://trac.tools.ietf.org/wg/clue/trac/ticket/8 (How consumer differentiates between multiple capture scenes) So, if folks could please respond to the following question with a "Yes" or "No": Should a human readable text string be added to the capture scene in the framework document? It would also be helpful (but not required for consensus) if folks could provide a brief statement justifying their response for the WG members that did not hear the discussion on today's call. The consensus call closes on Thursday at 5pm Pacific. Thanks, Mary CLUE WG co-chair On Fri, May 18, 2012 at 11:56 AM, Duckworth, Mark < Mark.Duckworth@polycom.com> wrote: > Regarding Ticket #8 - How consumer differentiates between multiple capture > scenes. > We discussed this a bit on the list, and on the April 10 phone meeting. I > think the group agreed we should add a human readable text string attribute > to a capture scene. > > Here is a proposal for adding text to the framework document section 6.2.1 > Capture scene attributes: > > Description attribute > > The description attribute is a human readable text string which describes > the capture scene. A provider that advertises multiple capture scenes may > use different descriptions to differentiate between them. > > > Do we also want to add a similar description attribute to a media capture? > > Mark Duckworth > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > --14dae9cdca9165ae8604c0a29ad5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all,

Per the design team meeting this morning, we are= doing a consensus call on the question as to whether human readable text s= tring should be added to the capture scene. =A0

No= te that while this came up during discussion of Ticket #8 in a previous mee= ting, it does not impact the state of Ticket #8 which remains open:
http://tr= ac.tools.ietf.org/wg/clue/trac/ticket/8 (How consumer differentiates be= tween multiple capture scenes)=A0

So, if folks cou= ld please respond to the following question with a "Yes" or "= ;No":

Should a human readable text string be added to the cap= ture scene in the framework document? =A0

It would= also be helpful (but not required for consensus) if folks could provide a = brief statement justifying their response for the WG members that did not h= ear the discussion on today's call.=A0

The consensus call closes on Thursday at 5pm Pacific.= =A0

Thanks,
Mary
CLUE WG co-ch= air




On Fri, May 18, 2012 at 11:56 AM, Duckworth, Mark <Mark.Duckworth= @polycom.com> wrote:
Regarding Ticket #8 - How consumer differentiates between multiple capture = scenes.
We discussed this a bit on the list, and on the April 10 phone meeting. =A0= I think the group agreed we should add a human readable text string attribu= te to a capture scene.

Here is a proposal for adding text to the framework document section 6.2.1 = Capture scene attributes:

Description attribute

The description attribute is a human readable text string which describes t= he capture scene. =A0A provider that advertises multiple capture scenes may= use different descriptions to differentiate between them.


Do we also want to add a similar description attribute to a media capture?<= br>
Mark Duckworth
_______________________________________________
clue mailing list
clue@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/clue

--14dae9cdca9165ae8604c0a29ad5-- From mary.ietf.barnes@gmail.com Tue May 22 09:36:36 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AC5C21F863D for ; Tue, 22 May 2012 09:36:36 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uhlX5UEKg7kM for ; Tue, 22 May 2012 09:36:35 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 499F521F848E for ; Tue, 22 May 2012 09:36:35 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so4882557vbb.31 for ; Tue, 22 May 2012 09:36:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=JB5hh7EGkESgh3nd/d4CoT3v7Q400Oo223B/YweFeys=; b=Xggbg8VTtp1WeWULudPpYeQweLWzah18VI+4NDeK2u/h3ilBat37Nd8yyF88XxtAZu 9d30wQ1847whttYMNUspSXczp2SxxNWpxdaGyMcVSJigzqehiJ+K5ZgnUkcgu8GP1vwk kzNmXA3hbag6ZKhzj0aJNY4IcyOAhGk2hZzCaoUy3AjjmIBSqkVPyCb9BHCRZwLQ1GWR dpfLrYeOuQb3Li+9bdBhoqkcBgeETJgu7PHQ+ZH3iYEN9q9gIWsuUNd5nhNoxov/Lm6Q w0kM8EYsiA8jqtvQMrIeVe7ecTebLV43Um8Wj8RfoS8tRCwSx3a+2dotEx/JVP+zE2Cn X9kA== MIME-Version: 1.0 Received: by 10.220.210.20 with SMTP id gi20mr1220969vcb.42.1337704594623; Tue, 22 May 2012 09:36:34 -0700 (PDT) Received: by 10.52.22.143 with HTTP; Tue, 22 May 2012 09:36:34 -0700 (PDT) Date: Tue, 22 May 2012 11:36:34 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=00221572766e2d4d3004c0a29fdb Subject: [clue] Consensus Call: Add description text to a capture scene? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 22 May 2012 16:36:36 -0000 --00221572766e2d4d3004c0a29fdb Content-Type: text/plain; charset=ISO-8859-1 Resending with a new Subject just to make sure folks pick up on this as a Consensus call. On Tue, May 22, 2012 at 11:35 AM, Mary Barnes wrote: > Hi all, > > Per the design team meeting this morning, we are doing a consensus call on > the question as to whether human readable text string should be added to > the capture scene. > > Note that while this came up during discussion of Ticket #8 in a previous > meeting, it does not impact the state of Ticket #8 which remains open: > http://trac.tools.ietf.org/wg/clue/trac/ticket/8 (How consumer > differentiates between multiple capture scenes) > > So, if folks could please respond to the following question with a "Yes" > or "No": > > Should a human readable text string be added to the capture scene in the > framework document? > > It would also be helpful (but not required for consensus) if folks could > provide a brief statement justifying their response for the WG members that > did not hear the discussion on today's call. > > The consensus call closes on Thursday at 5pm Pacific. > > Thanks, > Mary > CLUE WG co-chair > > > > > On Fri, May 18, 2012 at 11:56 AM, Duckworth, Mark < > Mark.Duckworth@polycom.com> wrote: > >> Regarding Ticket #8 - How consumer differentiates between multiple >> capture scenes. >> We discussed this a bit on the list, and on the April 10 phone meeting. >> I think the group agreed we should add a human readable text string >> attribute to a capture scene. >> >> Here is a proposal for adding text to the framework document section >> 6.2.1 Capture scene attributes: >> >> Description attribute >> >> The description attribute is a human readable text string which describes >> the capture scene. A provider that advertises multiple capture scenes may >> use different descriptions to differentiate between them. >> >> >> Do we also want to add a similar description attribute to a media capture? >> >> Mark Duckworth >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> > > --00221572766e2d4d3004c0a29fdb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Resending with a new Subject just to make sure folks pick up on this as a C= onsensus call.

On Tue, May 22, 2012 at 11= :35 AM, Mary Barnes <mary.ietf.barnes@gmail.com> wr= ote:
Hi all,

Per the design te= am meeting this morning, we are doing a consensus call on the question as t= o whether human readable text string should be added to the capture scene. = =A0

Note that while this came up during discussion of Ticke= t #8 in a previous meeting, it does not impact the state of Ticket #8 which= remains open:
http://trac.tools.ietf.org/wg/clue/trac/ticket/8 (How consumer= differentiates between multiple capture scenes)=A0

So, if folks could please respond to the following question with a "Ye= s" or "No":

Should a human readable text string be added to the cap= ture scene in the framework document? =A0

It would= also be helpful (but not required for consensus) if folks could provide a = brief statement justifying their response for the WG members that did not h= ear the discussion on today's call.=A0

The consensus call closes on Thursday at 5pm Pacific.= =A0

Thanks,
Mary
CLUE WG co-ch= air




On Fri, May 18, 2012 at 11:56 AM, Duckworth, Mark <Mark.Duckworth= @polycom.com> wrote:
Regarding Ticket #8 - How consumer differentiates between multiple capture = scenes.
We discussed this a bit on the list, and on the April 10 phone meeting. =A0= I think the group agreed we should add a human readable text string attribu= te to a capture scene.

Here is a proposal for adding text to the framework document section 6.2.1 = Capture scene attributes:

Description attribute

The description attribute is a human readable text string which describes t= he capture scene. =A0A provider that advertises multiple capture scenes may= use different descriptions to differentiate between them.


Do we also want to add a similar description attribute to a media capture?<= br>
Mark Duckworth
_______________________________________________
clue mailing list
clue@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/clue


--00221572766e2d4d3004c0a29fdb-- From mary.ietf.barnes@gmail.com Tue May 22 09:55:54 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D869021F84B6 for ; Tue, 22 May 2012 09:55:54 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C0YYKDXAwDOe for ; Tue, 22 May 2012 09:55:54 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id E482921F8503 for ; Tue, 22 May 2012 09:55:53 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so4890754vbb.31 for ; Tue, 22 May 2012 09:55:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=CFqQMaR51BQvM1RfzrVV1LB4FbqQn3Md1VBFfi2fMN0=; b=ASay0wz08LIOuKO9vFuqn2rTSpUMmWtCtT3Wf5PQrum90gOuXzj5UlKx2+VtmQfIb3 lrQcoqD3piF+q2CPt1Y7e3LdxWtMOoxjV+T6HhggfamyS7PJxeFFXy/NvUDCaSIVGh26 io6tRVAcMaWk9knk+vKWIfsqtaVV9kYcrS7z1MqI6emFO2yMXSB9phyC0ba0aKEgIKYC AOBDcnEr7layahHQRYEUo7IXsepkysfTWUENLhLbh6/+tLAgd0mLQ0DutrC9s5y8Y1hM 92oZiAA9O1GrxyMzGEajrJmGDRl7RCWpixw/KaA9lG1kmcLRGMbZlLABqKQyh9Wtk9DK 5+bw== MIME-Version: 1.0 Received: by 10.52.28.71 with SMTP id z7mr11130847vdg.105.1337705753476; Tue, 22 May 2012 09:55:53 -0700 (PDT) Received: by 10.52.22.143 with HTTP; Tue, 22 May 2012 09:55:53 -0700 (PDT) Date: Tue, 22 May 2012 11:55:53 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [clue] Updates to CLUE information transport criteria from May 22 DT meeting X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 22 May 2012 16:55:55 -0000 Hi all, This is a summary of updates proposed during today's design team meeting, based on Christer's original proposal and Roni's suggested additions: http://www.ietf.org/mail-archive/web/clue/current/msg01433.html Note, this a very important thread of discussion as we really need someone to step forward to take on detailing the data model and evaluate each of the data elements against this criteria: 1) Whether signaling intermediaries (e.g. SBGs) need to have access to the information - i.e.. whether information is relevant to routing decisions, policies as to how to route, etc. =A0-- Whether the CLUE information and the media description (SDP) need to be in the same message. -- Whether the CLUE information and the media description (SDP) need to use the same transport path. =A02) The expected size of the information to be sent (i.e., estimate of by= tes) =A03) The expected frequency of the information to be sent (i.e., 3 categories, per earlier discussion...) =A04) Whether the information is sent during session establishment, mid- session and/or session termination. -- Information for SIP session establishment -- Information about CLUE, information about media, information to establish media =A05) What delay is acceptable for the information (i.e., CLUE data element= ) 6) Whether the information is sent as a notification, or whether some kind of response is needed -- Does information need to be carried in a request and response or -- is it just necessary to be communicated one way =A07) Whether the information needs to be delivered reliably (either using=A0 a reliable transport mechanism, and/or some kind of higher-level=A0 acknowledgement) 8) Whether the information is needed by a non-CLUE entity in order to participate in a CLUE conference -- Not sure the intent here. Christer, can you please clarify what you mean by non-CLUE. Also, are you talking about some sort of mapping or is this a more theoretical question? Thanks, Mary. From mary.ietf.barnes@gmail.com Tue May 22 09:59:19 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBEDE21F84B6 for ; Tue, 22 May 2012 09:59:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gNxSMRUjnCn4 for ; Tue, 22 May 2012 09:59:18 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6E47221F8567 for ; Tue, 22 May 2012 09:59:18 -0700 (PDT) Received: by vcqp1 with SMTP id p1so743504vcq.31 for ; Tue, 22 May 2012 09:59:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=1+XTtGsDQH87N3pmZSJJzEgoD4oFGPk7/hKOwO85Fa4=; b=tPdntJ6NjyLXQ1LJTVT1sHrMP+oxvqwIHS/JnM4nRVYSgBBCTJ9rRT0lU8d6cZuIm9 1B6k7T+wUb+4jfSrMZ/acgJD17sVvMqpkG5nBwZMF8HS132GVy6eCACfwPvy0+yr5SwK 45aO29o0G+oaRM+trsBdGpjDkliSLZFz1EnKIJ6fAyltk6JGEbXIm5aop1OxSWLk4Lyz 1o7uz3jl38NvnwAN0Re1GXndR0WsL9uYSUMMUmFAZdWTB2lwuuJf737REbW7B5GpTOH8 glRD/8xplQM0Pa1VWE+IkBEnMmLiXl5QPKH5yYdGR5ncEVRMq7ubEEQTAW8TvF55ndCJ Nc9w== MIME-Version: 1.0 Received: by 10.220.63.9 with SMTP id z9mr1269978vch.64.1337705957309; Tue, 22 May 2012 09:59:17 -0700 (PDT) Received: by 10.52.22.143 with HTTP; Tue, 22 May 2012 09:59:17 -0700 (PDT) In-Reply-To: References: Date: Tue, 22 May 2012 11:59:17 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [clue] Topic: CLUE WG DT meeting tomorrow (May 22 @ 9am central) X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 22 May 2012 16:59:19 -0000 I have uploaded the minutes from the meeting: http://trac.tools.ietf.org/wg/clue/trac/wiki/Design-Team Thanks to John Leslie for again taking minutes. Note, I also added the dialin number for the calls to the wiki. Mary. On Mon, May 21, 2012 at 6:04 PM, Mary Barnes w= rote: > Hi all, > > Since it's been a few weeks since we have had a call, it would be good fo= r > us to have one this week and discuss some of the recent issues that have > been discussed on the mailing list. =A0While I don't necessarily like a > meeting because people aren't responding on the mailing list, I think som= e > of these topics would benefit from non-email discussion. > > 1) Criteria for CLUE signaling: > http://www.ietf.org/mail-archive/web/clue/current/msg01433.html =A0[Note: > Christer cannot make this meeting, but we can still review and decide > whether we agree this is a good starting point] > > 2) Ticket #8: add description text to a capture scene > http://www.ietf.org/mail-archive/web/clue/current/msg01442.html > > 3) Ticket #8: capture scene coordinates and content attribute > http://www.ietf.org/mail-archive/web/clue/current/msg01446.html > > Regards, > Mary. From marshall.eubanks@gmail.com Tue May 22 10:02:04 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED6AE21F8606 for ; Tue, 22 May 2012 10:02:04 -0700 (PDT) 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=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TBNVdLzz53iP for ; Tue, 22 May 2012 10:02:04 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6474521F8631 for ; Tue, 22 May 2012 10:02:04 -0700 (PDT) Received: by dacx6 with SMTP id x6so8715750dac.31 for ; Tue, 22 May 2012 10:02:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=MLd7lOdha+JaBTgeQiRtmbYqg5wKPHi3yCa5syTuw6E=; b=dUXs/++th1IguI2IU6wrR0/CuNRQnC0RaSrDGLx4p5ddlSLHFW5ZT/f2fLR0KMo1Cz Po14y417ZUrst5UXbDbY1LH9ISJfyfh+90tuTE5LZs2AvhXJkg7eESLzEAGKfM6AnUR8 oE5w+X3aENbrKQDvnR38dV4h398FofoI3T10Qm1Rli/G4H+cIoJYkNg8zu/tnXIRZtBU +XWliePz9eKzANhk829AUwQrw/T+kPuYRSFwx8HjrLcwWh+GxlrT1Oer5Vl99YCXZ2Dm vKuV8X4hht5tjs1lJHAHP67ShzEMzqEwFtWBsLJ87XYDdDR3/TB+p1vzcDrffKo2agz2 9aIA== MIME-Version: 1.0 Received: by 10.68.228.97 with SMTP id sh1mr426930pbc.113.1337706124018; Tue, 22 May 2012 10:02:04 -0700 (PDT) Received: by 10.68.58.68 with HTTP; Tue, 22 May 2012 10:02:03 -0700 (PDT) In-Reply-To: References: Date: Tue, 22 May 2012 13:02:03 -0400 Message-ID: From: Marshall Eubanks To: Mary Barnes Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: CLUE Subject: Re: [clue] Add description text to a capture scene X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 22 May 2012 17:02:05 -0000 On Tue, May 22, 2012 at 12:35 PM, Mary Barnes wrote: > Hi all, > > Per the design team meeting this morning, we are doing a consensus call o= n > the question as to whether human readable text string should be added to = the > capture scene. > > Note that while this came up during discussion of Ticket #8 in a previous > meeting, it does not impact the state of Ticket #8 which remains open: > http://trac.tools.ietf.org/wg/clue/trac/ticket/8 (How consumer > differentiates between multiple capture scenes) > > So, if folks could please respond to the following question with a "Yes" = or > "No": > > Should a human readable text string be added to the capture scene in the > framework document? Should is ambiguous. Do you mean an optional or a mandatory human readable text string ? If you mean optional, I would say Yes. The ability to add comments is always useful, and in some cases might be essential. Regards Marshall > > It would also be helpful (but not required for consensus) if folks could > provide a brief statement justifying their response for the WG members th= at > did not hear the discussion on today's call. > > The consensus call closes on Thursday at 5pm Pacific. > > Thanks, > Mary > CLUE WG co-chair > > > > > On Fri, May 18, 2012 at 11:56 AM, Duckworth, Mark > wrote: >> >> Regarding Ticket #8 - How consumer differentiates between multiple captu= re >> scenes. >> We discussed this a bit on the list, and on the April 10 phone meeting. = =A0I >> think the group agreed we should add a human readable text string attrib= ute >> to a capture scene. >> >> Here is a proposal for adding text to the framework document section 6.2= .1 >> Capture scene attributes: >> >> Description attribute >> >> The description attribute is a human readable text string which describe= s >> the capture scene. =A0A provider that advertises multiple capture scenes= may >> use different descriptions to differentiate between them. >> >> >> Do we also want to add a similar description attribute to a media captur= e? >> >> Mark Duckworth >> _______________________________________________ >> 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 > From pkyzivat@alum.mit.edu Tue May 22 10:02:45 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6744B21F8630 for ; Tue, 22 May 2012 10:02:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.785 X-Spam-Level: X-Spam-Status: No, score=-2.785 tagged_above=-999 required=5 tests=[AWL=-0.186, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1H73vEKr2dyj for ; Tue, 22 May 2012 10:02:45 -0700 (PDT) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [76.96.62.16]) by ietfa.amsl.com (Postfix) with ESMTP id BC80921F8606 for ; Tue, 22 May 2012 10:02:44 -0700 (PDT) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta01.westchester.pa.mail.comcast.net with comcast id Cytx1j00C1ap0As5152gK3; Tue, 22 May 2012 17:02:40 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta22.westchester.pa.mail.comcast.net with comcast id D52f1j00Z07duvL3i52f6n; Tue, 22 May 2012 17:02:39 +0000 Message-ID: <4FBBC6AF.2060405@alum.mit.edu> Date: Tue, 22 May 2012 13:02:39 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Mary Barnes References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: CLUE Subject: Re: [clue] Consensus Call: Add description text to a capture scene? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 22 May 2012 17:02:45 -0000 On 5/22/12 12:36 PM, Mary Barnes wrote: > Should a human readable text string be added to the capture scene in > the framework document? Yes. I don't think this is sufficient, but I think it is helpful, especially to have a way to get things working when better forms of interop fail. (If what you are seeing is unacceptable to you, then ideally you could pull up a control UI that describes what is available and make some alternative choices about what is to be displayed. This might occur because you are interoperating with a room from another vendor that you have not connected to before.) Also, AFAIK, it is valid for an MCU to "pass through" some or all of the scenes it receives in the advertisements it sends. This could be in lieu of doing its own composition into an aggregate scene, or as a supplement/alternative to an aggregated scene. When doing that, it would be very helpful to have a human description of the source for each scene. Thanks, Paul (as individual) From mary.ietf.barnes@gmail.com Tue May 22 10:09:04 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F179821F867D for ; Tue, 22 May 2012 10:09:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o1dvnYXFFmNT for ; Tue, 22 May 2012 10:09:03 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id DBC9321F867A for ; Tue, 22 May 2012 10:09:02 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so4897268vbb.31 for ; Tue, 22 May 2012 10:09:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=3/NKX951iJO816DYZuvG7kedjKgwct0ocQs6d/1Kc3s=; b=BtC3tnUoex25ALPGTf48yarfcmMucZUOdtkdezUB3BZwCkptwYSL0rPrFmz4qiwEg+ 2o6HKCT1/wWDGS5I/LpIdmMGH6ho9/b9HEP+m58mFXw5lAzYBu6wpRIeFGW84vmQK4Qf Y9DPEDivfrDVvxX+VTP3mew9oB85wN/ClMlb59EgpeJNxvd/8iGzQeT+rSp8FL/4PMXT PT30aH3/n5i4FWVTkUEcOdXw2IlA2r9438lGeP7No4/Kdr+6O+DEOYDNgBAmaUcgV6hF sTtFsTJdSi4bZmnPSRY5KxJtRH+bhUV9j6I/snbDFO0+EkNAm2gv/p/q2UdMwS9OdV4Y 2bRA== MIME-Version: 1.0 Received: by 10.220.221.139 with SMTP id ic11mr1266125vcb.74.1337706542400; Tue, 22 May 2012 10:09:02 -0700 (PDT) Received: by 10.52.22.143 with HTTP; Tue, 22 May 2012 10:09:02 -0700 (PDT) Date: Tue, 22 May 2012 12:09:02 -0500 Message-ID: From: Mary Barnes To: Marshall Eubanks Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: CLUE Subject: [clue] Consensus call: Add description text to a capture scene [Note subject changed] X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 22 May 2012 17:09:04 -0000 That's a good point. We did discuss the optionality on the call and it seemed that the folks that did not want it did not think it should be optional either. But, we can go ahead and pose the following questions then: 1) Do you agree that we should add a mandatory element with human readable text to the capture scene? 2) Do you agree that we should add an optional element with human readable text to the capture scene? 3) Do you agree that we should not add any optional or mandatory human readable text to the capture scene? Note, I have changed the subject for this thread and will repost the above to the other thread, so it's easier to track things. Thanks, Mary. On Tue, May 22, 2012 at 12:02 PM, Marshall Eubanks wrote: > On Tue, May 22, 2012 at 12:35 PM, Mary Barnes > wrote: >> Hi all, >> >> Per the design team meeting this morning, we are doing a consensus call = on >> the question as to whether human readable text string should be added to= the >> capture scene. >> >> Note that while this came up during discussion of Ticket #8 in a previou= s >> meeting, it does not impact the state of Ticket #8 which remains open: >> http://trac.tools.ietf.org/wg/clue/trac/ticket/8 (How consumer >> differentiates between multiple capture scenes) >> >> So, if folks could please respond to the following question with a "Yes"= or >> "No": >> >> Should a human readable text string be added to the capture scene in the >> framework document? > > Should is ambiguous. Do you mean an optional or a mandatory human > readable text string ? > > If you mean optional, I would say Yes. The ability to add comments is > always useful, and in some cases > might be essential. > > Regards > Marshall > >> >> It would also be helpful (but not required for consensus) if folks could >> provide a brief statement justifying their response for the WG members t= hat >> did not hear the discussion on today's call. >> >> The consensus call closes on Thursday at 5pm Pacific. >> >> Thanks, >> Mary >> CLUE WG co-chair >> >> >> >> >> On Fri, May 18, 2012 at 11:56 AM, Duckworth, Mark >> wrote: >>> >>> Regarding Ticket #8 - How consumer differentiates between multiple capt= ure >>> scenes. >>> We discussed this a bit on the list, and on the April 10 phone meeting.= =A0I >>> think the group agreed we should add a human readable text string attri= bute >>> to a capture scene. >>> >>> Here is a proposal for adding text to the framework document section 6.= 2.1 >>> Capture scene attributes: >>> >>> Description attribute >>> >>> The description attribute is a human readable text string which describ= es >>> the capture scene. =A0A provider that advertises multiple capture scene= s may >>> use different descriptions to differentiate between them. >>> >>> >>> Do we also want to add a similar description attribute to a media captu= re? >>> >>> Mark Duckworth >>> _______________________________________________ >>> 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 >> From mary.ietf.barnes@gmail.com Tue May 22 10:10:34 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C91E321F867A for ; Tue, 22 May 2012 10:10:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uQT2VFF4q9gb for ; Tue, 22 May 2012 10:10:34 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2A0BB21F8624 for ; Tue, 22 May 2012 10:10:34 -0700 (PDT) Received: by vcqp1 with SMTP id p1so746516vcq.31 for ; Tue, 22 May 2012 10:10:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=4/IOqdmKkPHi5WZa0Z0EFBH2acBsmE+Eo/Tyc7uPMPY=; b=CHi44Tq1chS9w33+jtWeOEwFmUNSta6IRr/ZkXy31/zaMJ5z/N4WbG41CUxbxINhrn kSi1/utOONSvvcJfCx7J7HUTq1nfV8cma9VFwW5wgW4QIDI1ZLPVu0nKWMXNjXmKs+Oa zL/hz2kdu+L9a7dKair0JRaCuMIQ09Fd78jl8dhVKy2vdlH20Yu30NZWniwCYbm7mYZ1 5zD2hmV82Cy5+Fa5TWS9h6BjuYIroqYaeUsKfJgWID4qZ3tXzhl3D+wfA75njG35T9A3 3fZD617hmHNaev5+p6oGxbDjrB2x2mcIop19YMm+DJTiCL2RuqjOjyY9GAt/ReO/R7f8 if7g== MIME-Version: 1.0 Received: by 10.52.173.209 with SMTP id bm17mr11350648vdc.54.1337706633735; Tue, 22 May 2012 10:10:33 -0700 (PDT) Received: by 10.52.22.143 with HTTP; Tue, 22 May 2012 10:10:33 -0700 (PDT) Date: Tue, 22 May 2012 12:10:33 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [clue] *Updated Consensus Call*: Add description text to a capture scene? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 22 May 2012 17:10:34 -0000 Per Marshall's feedback, I am reposing the questions to consider the optional aspect (which is what I think we have been discussing, but just to be clear). 1) Do you agree that we should add a mandatory element with human readable text to the capture scene? 2) Do you agree that we should add an optional element with human readable text to the capture scene? 3) Do you agree that we should not add any optional or mandatory human readable text to the capture scene? Thanks, Mary. On Tue, May 22, 2012 at 11:36 AM, Mary Barnes wrote: > Resending with a new Subject just to make sure folks pick up on this as a > Consensus call. > > On Tue, May 22, 2012 at 11:35 AM, Mary Barnes > wrote: >> >> Hi all, >> >> Per the design team meeting this morning, we are doing a consensus call = on >> the question as to whether human readable text string should be added to= the >> capture scene. >> >> Note that while this came up during discussion of Ticket #8 in a previou= s >> meeting, it does not impact the state of Ticket #8 which remains open: >> http://trac.tools.ietf.org/wg/clue/trac/ticket/8 (How consumer >> differentiates between multiple capture scenes) >> >> So, if folks could please respond to the following question with a "Yes" >> or "No": >> >> Should a human readable text string be added to the capture scene in the >> framework document? >> >> It would also be helpful (but not required for consensus) if folks could >> provide a brief statement justifying their response for the WG members t= hat >> did not hear the discussion on today's call. >> >> The consensus call closes on Thursday at 5pm Pacific. >> >> Thanks, >> Mary >> CLUE WG co-chair >> >> >> >> >> On Fri, May 18, 2012 at 11:56 AM, Duckworth, Mark >> wrote: >>> >>> Regarding Ticket #8 - How consumer differentiates between multiple >>> capture scenes. >>> We discussed this a bit on the list, and on the April 10 phone meeting. >>> =A0I think the group agreed we should add a human readable text string >>> attribute to a capture scene. >>> >>> Here is a proposal for adding text to the framework document section >>> 6.2.1 Capture scene attributes: >>> >>> Description attribute >>> >>> The description attribute is a human readable text string which describ= es >>> the capture scene. =A0A provider that advertises multiple capture scene= s may >>> use different descriptions to differentiate between them. >>> >>> >>> Do we also want to add a similar description attribute to a media >>> capture? >>> >>> Mark Duckworth >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >> >> > From marshall.eubanks@gmail.com Tue May 22 10:11:09 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9651621F867D for ; Tue, 22 May 2012 10:11:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7LY1uCKwJPeD for ; Tue, 22 May 2012 10:11:09 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id EA64321F8624 for ; Tue, 22 May 2012 10:11:08 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so8857489pbc.31 for ; Tue, 22 May 2012 10:11:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=ZxmOfidR0YSbqZOShvdXeWUHVfqdXzyCibmpjaGpxfc=; b=MmFDiL37TMt6SFutkkWy2INixlwfNT8WA80JoXQb8LEFHkrBk2AZZEIvYEfoFxxmnd bmy35U8caC5WYUamq6rwBoqJ+n1BftjtUYkCkfbHsyWmF1EjoWEwfqiRhfbtdIOV8lax Yrp6U1eXMa7vQr5cJV1Q4tjS5n8xF5k3iGM5ScfX0K4mTd8su1agsgZp8yNNa831iCFs qYsYFToB2JcrfDqCY6qSxvvUP3zIW5Mop/5OVS71o4QuioZUIp/mtqJH8AefMOf1Aqog uxscJUO5hbZvkl4/U+fMh6bRk2xyCHs6lMPcOu+Ur6oTCp+hELPID4UBP1gQHuPn6lHT jahA== MIME-Version: 1.0 Received: by 10.68.197.231 with SMTP id ix7mr497489pbc.103.1337706667211; Tue, 22 May 2012 10:11:07 -0700 (PDT) Received: by 10.68.58.68 with HTTP; Tue, 22 May 2012 10:11:07 -0700 (PDT) In-Reply-To: References: Date: Tue, 22 May 2012 13:11:07 -0400 Message-ID: From: Marshall Eubanks To: Mary Barnes Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: CLUE Subject: Re: [clue] Consensus call: Add description text to a capture scene [Note subject changed] X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 22 May 2012 17:11:09 -0000 On Tue, May 22, 2012 at 1:09 PM, Mary Barnes w= rote: > That's a good point. =A0We did discuss the optionality on the call and > it seemed that the folks that did not want it did not think it should > be optional either. =A0But, we can go ahead and pose the following > questions then: > 1) Do you agree that we should add a mandatory element with human > readable text to the capture scene? No > 2) Do you agree that we should add an optional element with human > readable text to the capture scene? Yes. > 3) Do you agree that we should not add any optional or mandatory human > readable text to the capture scene? > No. Regards Marshall > Note, I have changed the subject for this thread and will repost the > above to the other thread, so it's easier to track things. > > Thanks, > Mary. > > On Tue, May 22, 2012 at 12:02 PM, Marshall Eubanks > wrote: >> On Tue, May 22, 2012 at 12:35 PM, Mary Barnes >> wrote: >>> Hi all, >>> >>> Per the design team meeting this morning, we are doing a consensus call= on >>> the question as to whether human readable text string should be added t= o the >>> capture scene. >>> >>> Note that while this came up during discussion of Ticket #8 in a previo= us >>> meeting, it does not impact the state of Ticket #8 which remains open: >>> http://trac.tools.ietf.org/wg/clue/trac/ticket/8 (How consumer >>> differentiates between multiple capture scenes) >>> >>> So, if folks could please respond to the following question with a "Yes= " or >>> "No": >>> >>> Should a human readable text string be added to the capture scene in th= e >>> framework document? >> >> Should is ambiguous. Do you mean an optional or a mandatory human >> readable text string ? >> >> If you mean optional, I would say Yes. The ability to add comments is >> always useful, and in some cases >> might be essential. >> >> Regards >> Marshall >> >>> >>> It would also be helpful (but not required for consensus) if folks coul= d >>> provide a brief statement justifying their response for the WG members = that >>> did not hear the discussion on today's call. >>> >>> The consensus call closes on Thursday at 5pm Pacific. >>> >>> Thanks, >>> Mary >>> CLUE WG co-chair >>> >>> >>> >>> >>> On Fri, May 18, 2012 at 11:56 AM, Duckworth, Mark >>> wrote: >>>> >>>> Regarding Ticket #8 - How consumer differentiates between multiple cap= ture >>>> scenes. >>>> We discussed this a bit on the list, and on the April 10 phone meeting= . =A0I >>>> think the group agreed we should add a human readable text string attr= ibute >>>> to a capture scene. >>>> >>>> Here is a proposal for adding text to the framework document section 6= .2.1 >>>> Capture scene attributes: >>>> >>>> Description attribute >>>> >>>> The description attribute is a human readable text string which descri= bes >>>> the capture scene. =A0A provider that advertises multiple capture scen= es may >>>> use different descriptions to differentiate between them. >>>> >>>> >>>> Do we also want to add a similar description attribute to a media capt= ure? >>>> >>>> Mark Duckworth >>>> _______________________________________________ >>>> 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 >>> From mary.ietf.barnes@gmail.com Tue May 22 10:11:22 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E206B21F8682 for ; Tue, 22 May 2012 10:11:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TGqyX3hd+Awd for ; Tue, 22 May 2012 10:11:22 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4411D21F8680 for ; Tue, 22 May 2012 10:11:22 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so4898568vbb.31 for ; Tue, 22 May 2012 10:11:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=MY61tlbp3k2IjggNdb54Hwcavq1KUksFw/e7cBFWUQ0=; b=eCXX+sREsPLa4vsPfujM5/6RJhU9Swgj3R567/l64L63b7J3FwH8kn2XTRoSJ1iBwb OyTvaBK7B3xCEannewr1twegP/oFSaOhaDp3v0MwZxRGvTwR8Y4ZfslG32+A2wAnysXx mUC2y/vuSfSnVU8RZ+QhwDJxmjqIws1TcVbw4lmnqRr/bod8BWOnLcHMIfgYRpITbnXW XdhRba9/hMk4ypxC311nXp4N/EvRuqD7lQKlaLFezf6X14cEkLVJQgXsWIaz1nM1KwKz WCTSvVFKFOjljUAivdOkRwuN3+loWuoXvZNtCcuLXb3cKKrf5+aE0c7n2sxXzW49deuC vmHw== MIME-Version: 1.0 Received: by 10.52.28.71 with SMTP id z7mr11143837vdg.105.1337706681672; Tue, 22 May 2012 10:11:21 -0700 (PDT) Received: by 10.52.22.143 with HTTP; Tue, 22 May 2012 10:11:21 -0700 (PDT) In-Reply-To: <4FBBC6AF.2060405@alum.mit.edu> References: <4FBBC6AF.2060405@alum.mit.edu> Date: Tue, 22 May 2012 12:11:21 -0500 Message-ID: From: Mary Barnes To: Paul Kyzivat Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: CLUE Subject: Re: [clue] Consensus Call: Add description text to a capture scene? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 22 May 2012 17:11:23 -0000 Per my reposts on the question (considering Marshall's feedback), do you believe the string should be optional or mandatory? Thanks, Mary. On Tue, May 22, 2012 at 12:02 PM, Paul Kyzivat wrot= e: > On 5/22/12 12:36 PM, Mary Barnes wrote: > >> =A0 =A0Should a human readable text string be added to the capture scene= in >> =A0 =A0the framework document? > > > Yes. > > I don't think this is sufficient, but I think it is helpful, especially t= o > have a way to get things working when better forms of interop fail. (If w= hat > you are seeing is unacceptable to you, then ideally you could pull up a > control UI that describes what is available and make some alternative > choices about what is to be displayed. This might occur because you are > interoperating with a room from another vendor that you have not connecte= d > to before.) > > Also, AFAIK, it is valid for an MCU to "pass through" some or all of the > scenes it receives in the advertisements it sends. This could be in lieu = of > doing its own composition into an aggregate scene, or as a > supplement/alternative to an aggregated scene. When doing that, it would = be > very helpful to have a human description of the source for each scene. > > =A0 =A0 =A0 =A0Thanks, > =A0 =A0 =A0 =A0Paul (as individual) From marshall.eubanks@gmail.com Tue May 22 10:12:08 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBC6021F867D for ; Tue, 22 May 2012 10:12:08 -0700 (PDT) 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=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aBGixlPRNp22 for ; Tue, 22 May 2012 10:12:08 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0595021F8682 for ; Tue, 22 May 2012 10:12:07 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so8858572pbc.31 for ; Tue, 22 May 2012 10:12:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=UW9OCanEmx52//JwcEAJ883gKBgtJ19olrshgGle/ds=; b=YurVW2MN15AndJLGNS2K+AFNA4f56WviFu30ys5sQEjUaYgpEWB+TLJul9nh86cf1P 4x8TdGGD8EVkd2DRN8zQE9/bQzCy1AJKpD3jZM9P2q8keBt0/vb9IODvWHxVmqmfZJof ERIJRW1TWRjtubwruQXfJ3s4i7yrdzRxmMq1q2TVfVbszEVQg5GOSR/qRjEagtaWywTe LNEK21HroA1e3krBpJHDgrGtkMnRzRMjhMObh+j8Se3uc1Yeqs7h2g720UprDo2h0giV ZEISJb9KoDGCt6K+1nJRh7OpxaRaBshV2eVh/DAozpDVpSizYwrOTF343KPsfKWIfMDl 42IQ== MIME-Version: 1.0 Received: by 10.68.192.5 with SMTP id hc5mr661100pbc.49.1337706727752; Tue, 22 May 2012 10:12:07 -0700 (PDT) Received: by 10.68.58.68 with HTTP; Tue, 22 May 2012 10:12:07 -0700 (PDT) In-Reply-To: References: Date: Tue, 22 May 2012 13:12:07 -0400 Message-ID: From: Marshall Eubanks To: Mary Barnes Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: CLUE Subject: Re: [clue] *Updated Consensus Call*: Add description text to a capture scene? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 22 May 2012 17:12:09 -0000 Ok, one more time. On Tue, May 22, 2012 at 1:10 PM, Mary Barnes w= rote: > Per Marshall's feedback, I am reposing the questions to consider the > optional aspect (which is what I think we have been discussing, but > just to be clear). > > 1) Do you agree that we should add a mandatory element with human > readable text to the capture scene? No > 2) Do you agree that we should add an optional element with human > readable text to the capture scene? Yes > 3) Do you agree that we should not add any optional or mandatory human > readable text to the capture scene? No. Marshall > > Thanks, > Mary. > > On Tue, May 22, 2012 at 11:36 AM, Mary Barnes > wrote: >> Resending with a new Subject just to make sure folks pick up on this as = a >> Consensus call. >> >> On Tue, May 22, 2012 at 11:35 AM, Mary Barnes >> wrote: >>> >>> Hi all, >>> >>> Per the design team meeting this morning, we are doing a consensus call= on >>> the question as to whether human readable text string should be added t= o the >>> capture scene. >>> >>> Note that while this came up during discussion of Ticket #8 in a previo= us >>> meeting, it does not impact the state of Ticket #8 which remains open: >>> http://trac.tools.ietf.org/wg/clue/trac/ticket/8 (How consumer >>> differentiates between multiple capture scenes) >>> >>> So, if folks could please respond to the following question with a "Yes= " >>> or "No": >>> >>> Should a human readable text string be added to the capture scene in th= e >>> framework document? >>> >>> It would also be helpful (but not required for consensus) if folks coul= d >>> provide a brief statement justifying their response for the WG members = that >>> did not hear the discussion on today's call. >>> >>> The consensus call closes on Thursday at 5pm Pacific. >>> >>> Thanks, >>> Mary >>> CLUE WG co-chair >>> >>> >>> >>> >>> On Fri, May 18, 2012 at 11:56 AM, Duckworth, Mark >>> wrote: >>>> >>>> Regarding Ticket #8 - How consumer differentiates between multiple >>>> capture scenes. >>>> We discussed this a bit on the list, and on the April 10 phone meeting= . >>>> =A0I think the group agreed we should add a human readable text string >>>> attribute to a capture scene. >>>> >>>> Here is a proposal for adding text to the framework document section >>>> 6.2.1 Capture scene attributes: >>>> >>>> Description attribute >>>> >>>> The description attribute is a human readable text string which descri= bes >>>> the capture scene. =A0A provider that advertises multiple capture scen= es may >>>> use different descriptions to differentiate between them. >>>> >>>> >>>> Do we also want to add a similar description attribute to a media >>>> capture? >>>> >>>> Mark Duckworth >>>> _______________________________________________ >>>> 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 From john@jlc.net Tue May 22 10:20:38 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BF3721F85E6 for ; Tue, 22 May 2012 10:20:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YnQnz-JI+BxX for ; Tue, 22 May 2012 10:20:36 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 0C55821F85DF for ; Tue, 22 May 2012 10:20:31 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id B69C933C21; Tue, 22 May 2012 13:20:31 -0400 (EDT) Date: Tue, 22 May 2012 13:20:31 -0400 From: John Leslie To: Mary Barnes Message-ID: <20120522172031.GD2661@verdi> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Cc: CLUE Subject: Re: [clue] *Updated Consensus Call*: Add description text to a capture scene? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 22 May 2012 17:20:38 -0000 Mary Barnes wrote: > > 1) Do you agree that we should add a mandatory element with human > readable text to the capture scene? No. > 2) Do you agree that we should add an optional element with human > readable text to the capture scene? Yes. > 3) Do you agree that we should not add any optional or mandatory human > readable text to the capture scene? No. -- John Leslie From trac+clue@trac.tools.ietf.org Tue May 22 10:59:53 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF8D921F847B for ; Tue, 22 May 2012 10:59:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bF8Q0ImXHMSq for ; Tue, 22 May 2012 10:59:53 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 1870621F8475 for ; Tue, 22 May 2012 10:59:52 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1SWtMv-0005Yj-D6; Tue, 22 May 2012 13:59:37 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "clue issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: clue-chairs@tools.ietf.org, mary.ietf.barnes@gmail.com X-Trac-Project: clue Date: Tue, 22 May 2012 17:59:37 -0000 X-URL: http://tools.ietf.org/wg/clue/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/clue/trac/ticket/4#comment:1 Message-ID: <078.e755342f676b9805e6d25f46af19303e@trac.tools.ietf.org> References: <063.c25c26d18d12df129eb97ad25ea6bc92@trac.tools.ietf.org> X-Trac-Ticket-ID: 4 In-Reply-To: <063.c25c26d18d12df129eb97ad25ea6bc92@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: clue-chairs@tools.ietf.org, mary.ietf.barnes@gmail.com, clue@ietf.org X-SA-Exim-Mail-From: trac+clue@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Cc: clue@ietf.org Subject: Re: [clue] #4: Share CLUE metadata with W3C X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2012 17:59:54 -0000 #4: Share CLUE metadata with W3C Changes (by mary.ietf.barnes@…): * owner: draft-ietf-clue-framework@… => clue-chairs@… * component: framework => charter -- ------------------------+---------------------------- Reporter: pkyzivat@… | Owner: clue-chairs@… Type: task | Status: new Priority: major | Milestone: Component: charter | Version: Severity: - | Resolution: Keywords: | ------------------------+---------------------------- Ticket URL: clue From allyn@cisco.com Tue May 22 11:12:41 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAB4121F860D for ; Tue, 22 May 2012 11:12:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ImqINUQV8h91 for ; Tue, 22 May 2012 11:12:38 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 7BBD021F861B for ; Tue, 22 May 2012 11:12:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=allyn@cisco.com; l=11363; q=dns/txt; s=iport; t=1337710358; x=1338919958; h=mime-version:subject:date:message-id:from:to; bh=GQH562SlB4cYUjFfKBbDJkb5ycR/G3RIYj7A33OPgvo=; b=hjt60jzJfedT6L5cCBG1Zrq1YXzZUjuNgXNJ3fPMOEmTvICTpgJ4wTJQ dJu0vwAm6jQn9l2opsXbIcajGEBO4K3II/+QvuDnH3jWN8n89kJ54R7rC bTqyneAR1rqRFXBjoJqfjyTh2tAwkHQGbz7Cy+0oHH67ZuD6dhEF8RcKO 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAMrHu0+rRDoH/2dsb2JhbABEgkWxTYEHghcBBBIBCREDOCMBKgYYB1cBBBsah2sBmReBKJ93j2NiA4hDmmWBZIMK X-IronPort-AV: E=Sophos;i="4.75,639,1330905600"; d="scan'208,217";a="42795470" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-1.cisco.com with ESMTP; 22 May 2012 18:12:38 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q4MICcPn024238 for ; Tue, 22 May 2012 18:12:38 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, 22 May 2012 11:12:36 -0700 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_01CD3846.77E6BEE5" Date: Tue, 22 May 2012 11:12:34 -0700 Message-ID: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC0782890E@xmb-sjc-221.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: capture attributes - content attribute Thread-Index: Ac04RnZOA9sBnQ6tSvaEcDiurur32Q== From: "Allyn Romanow (allyn)" To: "CLUE" X-OriginalArrivalTime: 22 May 2012 18:12:36.0953 (UTC) FILETIME=[77A12C90:01CD3846] Subject: [clue] capture attributes - content attribute X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 22 May 2012 18:12:41 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD3846.77E6BEE5 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks,=20 Earlier we changed the capture attribute "purpose" with values presentation and main to content attribute taken from RFC 4976 with content types slides, main, speaker,=20 =20 Initially, when this came up, I thought it was a simple change and it had the appeal of using an existing RFC, so I wasn't opposed to it. However, in working on a proof of concept implementation, this seemed to have issues and I feel we should stay with purpose and main and presentation, or at the most, change it to content with main and slides as did the IMTC SIP Parity WG for Role Based Video Streams. =20 My primary reason for wanting to define only main and presentation (or content attributes main and slides from the full list in RFC 4796) is similar to the reasoning from the SIP Parity WG - that in a conference It can easily create confusion and lack of non-interoperability - for example one system may use main and another speaker when referring to the same situation. This same view was actually expressed in the Role Based Video Stream work in IMTC SIP Parity WG which decided to support only main and slides. =20 =20 Here is what is in the RBVS document on this topic (of course they aren't using the attributes for audio, just video). =20 Unlike H.239 where there are only two channel roles, "live" and "presentation", in SIP, there are more roles, and it is possible that endpoints and MCUs will have to deal with the situation where all of the participants in a call do not designate the same roles for their channels. For example, one endpoint in a multipoint conference may use the "speaker" and "slides" roles for its video channels, while another may use "main" and "alt" for its video channels. Since there are no mechanisms to enable MCUs and endpoints to interoperate in this type of situation, all SIP-based endpoints conforming to the RBVS "Best Practices" Profile MUST use the attributes as specified in this section. [ i.e., main and slides] The handling of other 'content' attribute values is considered out of scope. =20 =20 Although I'm okay with using just slides and main from the content attribute, I feel that purpose: presentation, main map better to audio than do slides and main. =20 I noticed today during the CLUE WG meeting that people reverted to speaking about purpose main and presentation instead of the new content attribute categories.. which is just an anecdote suggesting that we stick with what we first had. =20 Of course, I'm assuming that we add any values to purpose (or content) as they arise. =20 Thoughts? ------_=_NextPart_001_01CD3846.77E6BEE5 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Folks,

Earlier we changed  the capture attribute “purpose” with values presentation and main to content = attribute taken from RFC 4976 with content types slides, main, speaker, =

 

Initially, when this came up,  I thought it = was a simple change and it had the appeal of using an existing RFC, so I = wasn’t opposed to it. However, in working on a proof of concept implementation, = this seemed to have issues and  I feel we should stay with purpose and = main and presentation, or at the most, change it to content with main and slides = as did the IMTC SIP Parity WG for Role Based Video Streams.

 

My primary reason for wanting to define only main = and presentation (or content attributes main and slides from the full list = in RFC 4796) is similar to the reasoning from the SIP Parity WG – that in = a conference It can easily create  confusion and lack of = non-interoperability – for example one system may use main and another speaker when = referring to the same situation.    This same view was actually = expressed in the Role Based Video Stream work in IMTC SIP Parity WG which decided =  to support only main and slides.  

 

Here is what is in the RBVS document on this topic = (of course they aren’t using the attributes for audio, just = video).

 

Unlike H.239 where there are only two channel roles, “live” and “presentation”, in SIP, there are more roles, and it is = possible that endpoints and MCUs will have to deal with the situation where all = of the participants in a call do not designate the same roles for their = channels.  For example, one endpoint in a multipoint conference may use the “speaker” and “slides” roles for its video = channels, while another may use “main” and “alt” for its = video channels.   Since there are no mechanisms to enable MCUs and endpoints to interoperate in this type of situation, all SIP-based = endpoints conforming to the RBVS “Best Practices” Profile MUST use the attributes as specified in this section. [ i.e., main and slides] The = handling of other ‘content’ attribute values is considered out of = scope.

 

 

Although I’m okay with using just slides and = main from the content attribute, I feel that purpose: presentation, main map = better to audio than do slides and main.

 

I noticed today during the CLUE WG meeting that = people reverted to speaking about purpose main and presentation instead of the = new content attribute categories.. which is just an anecdote suggesting that = we stick with what we first had.

 

Of course, I’m assuming that we add any = values to purpose (or content) as they arise.

 

Thoughts?

------_=_NextPart_001_01CD3846.77E6BEE5-- From allyn@cisco.com Tue May 22 11:38:04 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3D8A21F85E6 for ; Tue, 22 May 2012 11:38:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z7OuUv5S4SUi for ; Tue, 22 May 2012 11:38:04 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 14AC221F85DD for ; Tue, 22 May 2012 11:38:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=allyn@cisco.com; l=2674; q=dns/txt; s=iport; t=1337711884; x=1338921484; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=vcyNm3nwq74Y5aujjvBVdDWxG7ffEcW29fGOHw2XDCM=; b=EhokP+CntanjmfWoLCF1Lv+Te8u9V/SY7W2TS67NKAHbSPg+hZwV1YyE xH3sVN6n5pp2KVtL8Lgwaw9uNSJCizkuxcJnjNplLgkHdXDiMa4F/cjCN ZJDHSWxFvZkWcEWwPQb8M9ow6pmFedXWKzrHiKMPTrXlIbpVx4FepR8b0 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAEDcu0+rRDoH/2dsb2JhbABEtBKBB4IVAQEBBAEBAQ8BHTcBBhcEAgEIEQQBAQsGFwEGASYfCQgBAQQBEggBGYVwgXsBC5pNn22LCBqEQWIDiBAzmmWBZIMKgT8 X-IronPort-AV: E=Sophos;i="4.75,639,1330905600"; d="scan'208";a="45825072" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 22 May 2012 18:38:03 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q4MIc3b8006290; Tue, 22 May 2012 18:38:03 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); Tue, 22 May 2012 11:38:03 -0700 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: Tue, 22 May 2012 11:38:01 -0700 Message-ID: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC07828940@xmb-sjc-221.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] Updates to CLUE information transport criteria from May 22DT meeting Thread-Index: Ac04O8qcTbwQuSFZQh+eyOeb5UjzoQADi57g References: From: "Allyn Romanow (allyn)" To: "Mary Barnes" , "CLUE" , "Andy Pepperell" X-OriginalArrivalTime: 22 May 2012 18:38:03.0601 (UTC) FILETIME=[05952C10:01CD384A] Subject: Re: [clue] Updates to CLUE information transport criteria from May 22DT meeting X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 22 May 2012 18:38:04 -0000 I thought Andy had agreed to do the data model- > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf = Of > Mary Barnes > Sent: Tuesday, May 22, 2012 9:56 AM > To: CLUE > Subject: [clue] Updates to CLUE information transport criteria from = May > 22DT meeting >=20 > Hi all, >=20 > This is a summary of updates proposed during today's design team > meeting, based on Christer's original proposal and Roni's suggested > additions: > http://www.ietf.org/mail-archive/web/clue/current/msg01433.html >=20 > Note, this a very important thread of discussion as we really need > someone to step forward to take on detailing the data model and > evaluate each of the data elements against this criteria: >=20 > 1) Whether signaling intermediaries (e.g. SBGs) need to have access to > the information - i.e.. whether information is relevant to routing > decisions, policies as to how to route, etc. >=20 > =A0-- Whether the CLUE information and the media description (SDP) = need > to be in the same message. >=20 > -- Whether the CLUE information and the media description (SDP) need > to use the same transport path. >=20 > =A02) The expected size of the information to be sent (i.e., estimate = of > bytes) >=20 > =A03) The expected frequency of the information to be sent (i.e., 3 > categories, per earlier discussion...) >=20 > =A04) Whether the information is sent during session establishment, = mid- > session and/or session termination. >=20 > -- Information for SIP session establishment >=20 > -- Information about CLUE, information about media, information to > establish media >=20 > =A05) What delay is acceptable for the information (i.e., CLUE data > element) >=20 > 6) Whether the information is sent as a notification, or whether some > kind of response is needed >=20 > -- Does information need to be carried in a request and response or >=20 > -- is it just necessary to be communicated one way >=20 > =A07) Whether the information needs to be delivered reliably (either > using=A0 a reliable transport mechanism, and/or some kind of > higher-level=A0 acknowledgement) >=20 > 8) Whether the information is needed by a non-CLUE entity in order to > participate in a CLUE conference >=20 > -- Not sure the intent here. Christer, can you please clarify what you > mean by non-CLUE. Also, are you talking about some sort of mapping or > is this a more theoretical question? >=20 >=20 >=20 > Thanks, > Mary. > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From mary.ietf.barnes@gmail.com Tue May 22 11:39:26 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A6F421F85F7 for ; Tue, 22 May 2012 11:39:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yB9a7jGGXpAn for ; Tue, 22 May 2012 11:39:25 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id F0AB221F85DD for ; Tue, 22 May 2012 11:39:24 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so4952417vbb.31 for ; Tue, 22 May 2012 11:39:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=Svcp3Fq2u4bEj2f0amAzAPyd4iICKO+zJ81M1rrz6jM=; b=CSd5JntqsxKKqHcX8kMmP+d8LpYIuNNMZ7p3z9NE7RataXgZHxkPmHzJotm3camFxt g+5/HT13XiOpEtb6yCpE/A/0cgqg9k6AwLxx02yqztIfN+pYSVl4UmfNxZyFnqunpE3i 6VPepHvMHECXdt/wKPLCM0WGjYhmysNoDr6yPLQlOQGl0zFm4bhN+54CSUkw4ZPyD9HU E27gWiJe9cJipgTs3NGD/uKGtyFik0benobHp0Szygx8xN0XijnNX3jiJbrZMiUHu7hh TUsBYKuw44at+LtWK+lbDdZeuOO8aq1nCeD/PwqfRrxJn9m+ur1gVwKtwe+xVCFtt47E hYdQ== MIME-Version: 1.0 Received: by 10.52.173.209 with SMTP id bm17mr11430431vdc.54.1337711964491; Tue, 22 May 2012 11:39:24 -0700 (PDT) Received: by 10.52.22.143 with HTTP; Tue, 22 May 2012 11:39:24 -0700 (PDT) Date: Tue, 22 May 2012 13:39:24 -0500 Message-ID: From: Mary Barnes To: Roni Even Content-Type: text/plain; charset=ISO-8859-1 Cc: clue@ietf.org Subject: [clue] A chair's response to: My view of CLUE status and topics for Interim meeting X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 22 May 2012 18:39:26 -0000 Roni, This is an excellent summary and pretty much is inline with the draft agenda on the wiki: http://trac.tools.ietf.org/wg/clue/trac/wiki I have some comments inline below [MB]. In summary, I think we need folks to agree to take on the following work items in preparation for the meeting - we already have folks that have come forward for some of them, but others are desperately needing some attention: 1) Call Flows (for framework) [???] 2) Data model - Christer has taken the lead on the criteria, but we need someone to put together a strawman XML model, as well as a complete summary of the elements (similar to what Allyn had in draft-romanow-clue-sdp-usage-01). 3) Transport/signaling - I believe most of the proposals need refinement based upon discussions from IETF-83. And, better yet, It may be possible to combine several or for the proposals to at least consider/compare the other relevant documents. [Please let the chairs know if you haven't already if you are planning updates to existing proposals or whether you will have a new proposal]. 4) RTP: Usage and mapping CLUE media captures [Jonathan and Roni are working in this area. Roni has already indicated to the chairs that he will update his draft. In addition, Magnus has requested agenda time to discuss these additional points: - Security - Congestion Control - Distribution of complexity - Transport implications - Handling of identities] As a reminder, the deadline to request agenda time is this coming Friday (May 25). Note that you don't need to have a draft submitted yet - the chairs just need to know that you are intending to put something forth. Ideally, we do need drafts so folks have sufficient background before we discuss the topic at the meeting. The draft deadline is Wednesday May 30th (one week before the meeting is to be held). But, please do let the chairs know if you have any issues surrounding the dates. We will use our discretion in considering items for the agenda with priority going to topics with documents submitted by the deadline. However, we recognize it is more important to have material for discussion than to meet absolute deadlines. We will have a draft agenda out on June 1st. We will need the presentations by June 4th as the chairs will be traveling and I won't arrive until the evening of the 6th. Also, we have remote participants, thus we must ensure that they have access to the presentations ahead of time. Note that all these dates are summarized on the wiki: http://trac.tools.ietf.org/wg/clue/trac/wiki One final comment, we do need a fairly accurate headcount as Ericsson will be providing refreshments (including lunch ;). I am using the meeting location doodle to track the headcount. So, if folks have not responded to that doodle or contacted the chairs directly, please do so ASAP: http://www.doodle.com/wwrdycma9ymrdn3r Thanks, Mary On Tue, May 22, 2012 at 4:34 AM, Roni Even wrote: > > > Hi Guys, > > I think that we are in a good shape in the framework and think that in order > to expedite the work we need to address the following topic and I think it > will be good use of our time to do it in the Interim meeting. [MB] I do agree that we are very close to resolving framework issues, although for Ticket #5 for example, we have discussed that we may need to have more information about the signaling to resolve. I believe an objective should be to leave the interim with all the current issues for the framework resolved (certainly, new issues may arise as we work through the solution details). It is possible that we will agree for Ticket #10, as well that we may need to see how the signaling falls out to ensure it is resolved. There has also been some feedback that the structure of the framework document can be difficult for someone outside CLUE to easily read. I think that's a combination of not enough intro/front material in the framework document and the fact that some level of knowledge in this subject is a necessity to fully understanding the content (i.e., this is not a primer for Telepresence). I have asked the ADs if we could possibly schedule a tutorial at IETF-84 to cover some of the higher level aspects that folks are missing that might better help them understand the context of the framework, etc. [/MB] > > These are the topics as I see them. Please feel free to comment. > > > > Data model > > At the last Interim meeting in February Andy presented an initial data > structure in > http://www.ietf.org/proceedings/interim/2012/02/15/clue/slides/clue-5.doc . [MB] My only concern with what Andy presented was that it was a signaling model that included the data that needed to be carried and not explicitly a data model, although it should be fairly straightforward to derive the data model from that. [/MB] > This is an XML schema that has the outline of the data but it is very basic > and need more work. [MB] Per my comment above, this is a signaling model based on XML. [/MB] > There was a discussion if the encoding group information > can be described using SDP and > http://tools.ietf.org/html/draft-romanow-clue-sdp-usage-01 is an attempt to > describe the encoding groups in SDP. It was presented in IETF83 (Paris) but > there was no real progress or discussion since then. [MB] In my mind, this isn't a data model thing as much as it is a draft that is relevant to the signaling. Although, certainly the information elements defined in that document should be part of the data model. [/MB] > > CLUE transport. > > The group is still evaluating what is the right transport for the CLUE > protocol. The major options are using a second MIME body in offer answer > (similar to the approach taken in SIPREC > http://tools.ietf.org/html/draft-ietf-siprec-protocol-03 ) or using RFC3264 > offer answer to negotiate an end to end channel that will carry the CLUE > protocol (maybe something like BFCP). The draft > http://tools.ietf.org/html/draft-wenger-clue-transport-02 was presented in > IETF83 (Paris) but the issue is still open. > > Some other work on the topic is in > http://tools.ietf.org/html/draft-cazeaux-clue-sip-signaling-01 which > suggests using SDP with offer answer. [MB] We agreed at IETF-83 that we would not adopt a model whereby all the signaling is done with SDP. [/MB] > > http://tools.ietf.org/html/draft-hansen-clue-protocol-choices-evaluation-00 > is trying to evaluate both transport options. > > The solution should take into account the call flow which is still an open > issue. [MB] The solution really needs to take into account the data model and the criteria we have been discussing. [/MB] > > CLUE call flow > > The framework talks about 3 messages (consumer capabilities, provider > advertisement and consumer configuration). There is an ongoing discussion if > we need all three and how they fit with the offer answer exchange. The more > general question is how many messages it take to establish a TP call. While > the provider advertisement and consumer configuration are used to negotiate > the media captures that will be used in the call it is not clear why we need > the consumer capability. The justification for the consumer capabilities may > be to allow the provider to advertise the relevant capture scene entries, > for example a 3 camera system sending an advertisement to a 2 screen system > may offer only capture scene entries relevant to two screens system. > > This subject is relevant to the CLUE transport work which will include the > call flows. [MB] We really do need someone to step forward for the call flows and put some of those together. Even if we just start with .ppt that we can upload to the wiki, we can later convert to ascii art (there are tools available and some of us find ascii art to be a relaxing (constructive) distraction). The XCON scenarios (RFC 4597) mapping to XCON framework (RFC 5239) examples (section 9) provide a reasonable model for what I would expect at this point in time for the framework. After we get all the signaling done, we can then do very detailed call flows along the lines of RFC 6504. [/MB] > > Mapping of CLUE media captures to RTP payload (SSRC and payload type number) > > The media captures provide information about constrains of the streams and > the spatial relation between them. The streams themselves are described in > SIP using SDP and they can be identified by their SSRC numbers. The mapping > between these two is important to allow the receiver of the RTP stream to > know where to display them. > http://tools.ietf.org/html/draft-even-clue-rtp-mapping-01 is trying to > propose a solution but need more work. There is a similar requirement in > RTCweb and http://tools.ietf.org/html/draft-alvestrand-rtcweb-msid-01 tries > a different approach. In IETF83 the author of the RTCweb draft was asked to > look at using grouping and SSRC for this mapping. This may require new > attribute to the SSRC SDP attribute. > > > > RTP usage in CLUE > > This topic is about multiplexing RTP streams in CLUE. In RTCweb the > direction is to multiple the audio and video in one UDP session and work is > now in progress in AVTcore and MMUSIC to address this requirement. In CLUE > it is desirable to multiplex all the video streams in one UDP connection. > http://tools.ietf.org/html/draft-lennox-clue-rtp-usage-03 present and > recommends the RTP multiplexing mechanism. > > Thanks > > Roni > > From john@jlc.net Tue May 22 11:42:20 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4B3321F8673 for ; Tue, 22 May 2012 11:42:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jvlq9F7CqFI3 for ; Tue, 22 May 2012 11:42:20 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 4E33221F8647 for ; Tue, 22 May 2012 11:42:20 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 5E40733C22; Tue, 22 May 2012 14:42:20 -0400 (EDT) Date: Tue, 22 May 2012 14:42:20 -0400 From: John Leslie To: "Allyn Romanow (allyn)" Message-ID: <20120522184220.GE2661@verdi> References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC0782890E@xmb-sjc-221.amer.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC0782890E@xmb-sjc-221.amer.cisco.com> User-Agent: Mutt/1.4.1i Cc: CLUE Subject: Re: [clue] capture attributes - content attribute X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 22 May 2012 18:42:21 -0000 Allyn Romanow (allyn) wrote: > > Earlier we changed the capture attribute "purpose" with values > presentation and main to content attribute taken from RFC 4976 with > content types slides, main, speaker, > > Initially, when this came up, I thought it was a simple change and it > had the appeal of using an existing RFC, so I wasn't opposed to it. > However, in working on a proof of concept implementation, this seemed to > have issues and I feel we should stay with purpose and main and > presentation, or at the most, change it to content with main and slides > as did the IMTC SIP Parity WG for Role Based Video Streams. "Main" leaves me cold, to tell truth; "Presentation" may be marginally better than "slides" -- but I can't see this as worth revisiting. Whatever we do needs to be extensible, and "speaker" will likely deserve distinctions, not absorbtion into another content type. (For a few examples of where we may want to expand, consider "panel" and "moderator"...) > My primary reason for wanting to define only main and presentation (or > content attributes main and slides from the full list in RFC 4796) is > similar to the reasoning from the SIP Parity WG - that in a conference > It can easily create confusion and lack of non-interoperability - for > example one system may use main and another speaker when referring to > the same situation. I don't believe we can avoid such issues -- even if we were to limit ourselves to only one allowed content-type. ;^) -- John Leslie From allyn@cisco.com Tue May 22 11:56:55 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20C1021F85AC for ; Tue, 22 May 2012 11:56:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1etloOylgY7S for ; Tue, 22 May 2012 11:56:54 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 424EA21F858A for ; Tue, 22 May 2012 11:56:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=allyn@cisco.com; l=2258; q=dns/txt; s=iport; t=1337713014; x=1338922614; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=fqfmZ2Rpd5GJFfBaW/aLkh6JcZfwNSlEUdPdORyWyTw=; b=XlX246qo7LCa1IkoL1vaHfiDUSewLwNJJCSLlHWQLLLj2IMlbfXOjJiJ qmgmF1VwOrEQhPoSY/Fu2g0I4K+B3DLNsIur0Qnb2aKl3nDYKHpOAk9Wi byB3sybL7PmkHeD90IRkEd5W4yUg2H6V+p9c6q+NhmvynssGiizC+eizQ E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAEbgu0+rRDoG/2dsb2JhbABEtBKBB4IVAQEBBBIBHQouEQwEAgEIEQQBAQEKBhcBBgFFCQgBAQQTCBqHawGaXZ9tiwgVhEZiA4hDmmWBZIMKgTc X-IronPort-AV: E=Sophos;i="4.75,639,1330905600"; d="scan'208";a="43341784" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 22 May 2012 18:56:54 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q4MIursW007645; Tue, 22 May 2012 18:56:53 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, 22 May 2012 11:56:52 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 22 May 2012 11:56:51 -0700 Message-ID: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC07828954@xmb-sjc-221.amer.cisco.com> In-Reply-To: <20120522184220.GE2661@verdi> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] capture attributes - content attribute Thread-Index: Ac04Sqd+4FlQ45WHQAOezoiNFaY41AAAb7ow References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC0782890E@xmb-sjc-221.amer.cisco.com> <20120522184220.GE2661@verdi> From: "Allyn Romanow (allyn)" To: "John Leslie" X-OriginalArrivalTime: 22 May 2012 18:56:52.0993 (UTC) FILETIME=[A6C0B710:01CD384C] Cc: CLUE Subject: Re: [clue] capture attributes - content attribute X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 22 May 2012 18:56:55 -0000 Hi John, My point wasn't really the name of the attributes, sorry if I expressed it poorly. It was to not use the full list of RFC 4796 attributes, but to limit to 2 of them... OR, I even prefer just going back to purpose with main and presentation.. but don't really object to content attributes if we sort out ones that make sense to me. > -----Original Message----- > From: John Leslie [mailto:john@jlc.net] > Sent: Tuesday, May 22, 2012 11:42 AM > To: Allyn Romanow (allyn) > Cc: CLUE > Subject: Re: [clue] capture attributes - content attribute >=20 > Allyn Romanow (allyn) wrote: > > > > Earlier we changed the capture attribute "purpose" with values > > presentation and main to content attribute taken from RFC 4976 with > > content types slides, main, speaker, > > > > Initially, when this came up, I thought it was a simple change and it > > had the appeal of using an existing RFC, so I wasn't opposed to it. > > However, in working on a proof of concept implementation, this seemed > to > > have issues and I feel we should stay with purpose and main and > > presentation, or at the most, change it to content with main and > slides > > as did the IMTC SIP Parity WG for Role Based Video Streams. >=20 > "Main" leaves me cold, to tell truth; "Presentation" may be > marginally > better than "slides" -- but I can't see this as worth revisiting. >=20 > Whatever we do needs to be extensible, and "speaker" will likely > deserve distinctions, not absorbtion into another content type. >=20 > (For a few examples of where we may want to expand, consider "panel" > and "moderator"...) >=20 > > My primary reason for wanting to define only main and presentation (or > > content attributes main and slides from the full list in RFC 4796) is > > similar to the reasoning from the SIP Parity WG - that in a conference > > It can easily create confusion and lack of non-interoperability - for > > example one system may use main and another speaker when referring to > > the same situation. >=20 > I don't believe we can avoid such issues -- even if we were to limit > ourselves to only one allowed content-type. ;^) >=20 > -- > John Leslie From christer.holmberg@ericsson.com Tue May 22 13:12:45 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBE6821F86B2 for ; Tue, 22 May 2012 13:12:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EykOXpWX-syf for ; Tue, 22 May 2012 13:12:45 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id A134521F85EF for ; Tue, 22 May 2012 13:12:44 -0700 (PDT) X-AuditID: c1b4fb2d-b7fac6d000002e89-6e-4fbbf33b5d80 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 9B.2A.11913.B33FBBF4; Tue, 22 May 2012 22:12:43 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.250]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Tue, 22 May 2012 22:12:42 +0200 From: Christer Holmberg To: Mary Barnes , CLUE Date: Tue, 22 May 2012 22:11:29 +0200 Thread-Topic: Updates to CLUE information transport criteria from May 22 DT meeting Thread-Index: Ac04O8Ained0A89IRfiU/p7mCPc5ZQAG1LKl Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C457B1389@ESESSCMS0356.eemea.ericsson.se> References: 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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrILMWRmVeSWpSXmKPExsUyM+Jvra71593+BosXiVjsP3WZ2eLz/v3M Fis2HGB1YPb4+/4Dk8fOWXfZPZYs+ckUwBzFZZOSmpNZllqkb5fAlXHmzGzmggaRiosti9kb GHsFuhg5OSQETCRun/nHAmGLSVy4t56ti5GLQ0jgFKPEoeXvWSCchYwSu2eeBMpwcLAJWEh0 /9MGaRARcJK48PI9WDOzgIbE5dtdbCA2i4CqROvJq8wg5cICIRI9H30gykMl1h/5zwhhG0m8 /nSRCcTmFQiXOLFoJZgtJBAgMavrF1gNp0CgxJ0ZrWBxRqDbvp9awwSxSlzi1pP5TBA3C0gs 2XOeGcIWlXj5+B8rRL2oxJ329YwQ9ToSC3Z/YoOwtSWWLXzNDLFXUOLkzCcsExjFZiEZOwtJ yywkLbOQtCxgZFnFKJybmJmTXm6ol1qUmVxcnJ+nV5y6iREYTQe3/NbdwXjqnMghRmkOFiVx 3s0Gu/yFBNITS1KzU1MLUovii0pzUosPMTJxcEo1MIbEGqy6fiZ7rYzmfu8Wxo23/9S31TpN 1u7fwL6PS/bwafNLh98a3Dul0WweJ9TzJERHPlxjSdHa68v4Thzpnun05vLtthsNfLJf/6gs llp2MkGDn93phq+4xhpnpoDQpXvrKgrMVebK+pzjfHHuzL0TvZ93vDzUxWS0qCTi8B7b17F9 PP2qHkosxRmJhlrMRcWJADu8CFx0AgAA Subject: Re: [clue] Updates to CLUE information transport criteria from May 22 DT meeting X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 22 May 2012 20:12:45 -0000 Hi Mary, My intention is to start mapping the criterias to the data model. However, I'd first like us to have an understanding/agreement on what the c= riterias are, and that's the reason I asked people to provide input on the = list. Regards, Christer ________________________________________ From: Mary Barnes [mary.ietf.barnes@gmail.com] Sent: Tuesday, May 22, 2012 7:55 PM To: CLUE Cc: Christer Holmberg; Paul Kyzivat Subject: Updates to CLUE information transport criteria from May 22 DT meet= ing Hi all, This is a summary of updates proposed during today's design team meeting, based on Christer's original proposal and Roni's suggested additions: http://www.ietf.org/mail-archive/web/clue/current/msg01433.html Note, this a very important thread of discussion as we really need someone to step forward to take on detailing the data model and evaluate each of the data elements against this criteria: 1) Whether signaling intermediaries (e.g. SBGs) need to have access to the information - i.e.. whether information is relevant to routing decisions, policies as to how to route, etc. -- Whether the CLUE information and the media description (SDP) need to be in the same message. -- Whether the CLUE information and the media description (SDP) need to use the same transport path. 2) The expected size of the information to be sent (i.e., estimate of byte= s) 3) The expected frequency of the information to be sent (i.e., 3 categories, per earlier discussion...) 4) Whether the information is sent during session establishment, mid- session and/or session termination. -- Information for SIP session establishment -- Information about CLUE, information about media, information to establish media 5) What delay is acceptable for the information (i.e., CLUE data element) 6) Whether the information is sent as a notification, or whether some kind of response is needed -- Does information need to be carried in a request and response or -- is it just necessary to be communicated one way 7) Whether the information needs to be delivered reliably (either using a reliable transport mechanism, and/or some kind of higher-level acknowledgement) 8) Whether the information is needed by a non-CLUE entity in order to participate in a CLUE conference -- Not sure the intent here. Christer, can you please clarify what you mean by non-CLUE. Also, are you talking about some sort of mapping or is this a more theoretical question? Thanks, Mary.= From pkyzivat@alum.mit.edu Tue May 22 15:49:54 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93F5821F85CF for ; Tue, 22 May 2012 15:49:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.762 X-Spam-Level: X-Spam-Status: No, score=-2.762 tagged_above=-999 required=5 tests=[AWL=-0.163, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B0DZSr3J5M4l for ; Tue, 22 May 2012 15:49:54 -0700 (PDT) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [76.96.59.243]) by ietfa.amsl.com (Postfix) with ESMTP id BB96C21F848F for ; Tue, 22 May 2012 15:49:53 -0700 (PDT) Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta13.westchester.pa.mail.comcast.net with comcast id D6rt1j0031vXlb85DAptLS; Tue, 22 May 2012 22:49:53 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta17.westchester.pa.mail.comcast.net with comcast id DAps1j01007duvL3dApscf; Tue, 22 May 2012 22:49:53 +0000 Message-ID: <4FBC1810.3080209@alum.mit.edu> Date: Tue, 22 May 2012 18:49:52 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: clue@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] Consensus call: Add description text to a capture scene [Note subject changed] X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 22 May 2012 22:49:54 -0000 On 5/22/12 1:09 PM, Mary Barnes wrote: > That's a good point. We did discuss the optionality on the call and > it seemed that the folks that did not want it did not think it should > be optional either. But, we can go ahead and pose the following > questions then: > 1) Do you agree that we should add a mandatory element with human > readable text to the capture scene? Yes. This might be controversial. The reason I say this is because in the absence of anything else it may not be possible to distinguish in any way between scenes. If there were some other guaranteed fallback then I would go for optional here. AFAIK we don't currently have anything that would even provide a means of correlating elements of two successive advertisements from the same source. If there are two scenes in the first advertisement, and three scenes in the second advertisement, am I guaranteed to know which ones in the 2nd advertisement correspond to those in the first? > 2) Do you agree that we should add an optional element with human > readable text to the capture scene? Yes, if not mandatory. > 3) Do you agree that we should not add any optional or mandatory human > readable text to the capture scene? No. IMO this is now structured in a confusing way. Its posed as three separate questions, but they aren't independent. If you agree with 3 then you must disagree with 1 & 2. If feels like these three should be alternatives, at least in terms of preferences. But if you agree with 1 then you might also consider 2 to be a valid second choice. Thanks, Paul (as individual) > Note, I have changed the subject for this thread and will repost the > above to the other thread, so it's easier to track things. > > Thanks, > Mary. > > On Tue, May 22, 2012 at 12:02 PM, Marshall Eubanks > wrote: >> On Tue, May 22, 2012 at 12:35 PM, Mary Barnes >> wrote: >>> Hi all, >>> >>> Per the design team meeting this morning, we are doing a consensus call on >>> the question as to whether human readable text string should be added to the >>> capture scene. >>> >>> Note that while this came up during discussion of Ticket #8 in a previous >>> meeting, it does not impact the state of Ticket #8 which remains open: >>> http://trac.tools.ietf.org/wg/clue/trac/ticket/8 (How consumer >>> differentiates between multiple capture scenes) >>> >>> So, if folks could please respond to the following question with a "Yes" or >>> "No": >>> >>> Should a human readable text string be added to the capture scene in the >>> framework document? >> >> Should is ambiguous. Do you mean an optional or a mandatory human >> readable text string ? >> >> If you mean optional, I would say Yes. The ability to add comments is >> always useful, and in some cases >> might be essential. >> >> Regards >> Marshall >> >>> >>> It would also be helpful (but not required for consensus) if folks could >>> provide a brief statement justifying their response for the WG members that >>> did not hear the discussion on today's call. >>> >>> The consensus call closes on Thursday at 5pm Pacific. >>> >>> Thanks, >>> Mary >>> CLUE WG co-chair >>> >>> >>> >>> >>> On Fri, May 18, 2012 at 11:56 AM, Duckworth, Mark >>> wrote: >>>> >>>> Regarding Ticket #8 - How consumer differentiates between multiple capture >>>> scenes. >>>> We discussed this a bit on the list, and on the April 10 phone meeting. I >>>> think the group agreed we should add a human readable text string attribute >>>> to a capture scene. >>>> >>>> Here is a proposal for adding text to the framework document section 6.2.1 >>>> Capture scene attributes: >>>> >>>> Description attribute >>>> >>>> The description attribute is a human readable text string which describes >>>> the capture scene. A provider that advertises multiple capture scenes may >>>> use different descriptions to differentiate between them. >>>> >>>> >>>> Do we also want to add a similar description attribute to a media capture? >>>> >>>> Mark Duckworth >>>> _______________________________________________ >>>> clue mailing list >>>> clue@ietf.org >>>> https://www.ietf.org/mailman/listinfo/clue >>> >>> >>> >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >>> > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From pkyzivat@alum.mit.edu Tue May 22 16:09:13 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36F2521F86C4 for ; Tue, 22 May 2012 16:09:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.744 X-Spam-Level: X-Spam-Status: No, score=-2.744 tagged_above=-999 required=5 tests=[AWL=-0.144, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MvDJHvG1JOIF for ; Tue, 22 May 2012 16:09:12 -0700 (PDT) Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [76.96.62.64]) by ietfa.amsl.com (Postfix) with ESMTP id 666A121F86B8 for ; Tue, 22 May 2012 16:09:12 -0700 (PDT) Received: from omta11.westchester.pa.mail.comcast.net ([76.96.62.36]) by qmta07.westchester.pa.mail.comcast.net with comcast id DAqb1j0020mv7h057B9Bkx; Tue, 22 May 2012 23:09:11 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta11.westchester.pa.mail.comcast.net with comcast id DB9B1j00H07duvL3XB9B1V; Tue, 22 May 2012 23:09:11 +0000 Message-ID: <4FBC1C97.3070201@alum.mit.edu> Date: Tue, 22 May 2012 19:09:11 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: clue@ietf.org References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC0782890E@xmb-sjc-221.amer.cisco.com> <20120522184220.GE2661@verdi> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC07828954@xmb-sjc-221.amer.cisco.com> In-Reply-To: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC07828954@xmb-sjc-221.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] capture attributes - content attribute X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 22 May 2012 23:09:13 -0000 Allyn, I'd like to understand better what the problem was that you encountered. I guess you must have had a situation when one impl used "speaker" and another used "main" for captures that were topologically and semantically equivalent. I understand how that could be a problem. But it seems like a problem that arises from insufficient definition of what the "purpose" values *mean*. That may mean we need to find a way to supplement the definitions from 4976. In rooms where the arrangement is always a line of people facing a line of screens and cameras there may not be a need for more than two purposes. But other arrangements, such as ones that have a distinguished speaker/presenter, may need more. Thanks, Paul On 5/22/12 2:56 PM, Allyn Romanow (allyn) wrote: > Hi John, > My point wasn't really the name of the attributes, sorry if I expressed > it poorly. > > It was to not use the full list of RFC 4796 attributes, but to limit to > 2 of them... > OR, I even prefer just going back to purpose with main and > presentation.. but don't really object to content attributes if we sort > out ones that make sense to me. > >> -----Original Message----- >> From: John Leslie [mailto:john@jlc.net] >> Sent: Tuesday, May 22, 2012 11:42 AM >> To: Allyn Romanow (allyn) >> Cc: CLUE >> Subject: Re: [clue] capture attributes - content attribute >> >> Allyn Romanow (allyn) wrote: >>> >>> Earlier we changed the capture attribute "purpose" with values >>> presentation and main to content attribute taken from RFC 4976 with >>> content types slides, main, speaker, >>> >>> Initially, when this came up, I thought it was a simple change and > it >>> had the appeal of using an existing RFC, so I wasn't opposed to it. >>> However, in working on a proof of concept implementation, this > seemed >> to >>> have issues and I feel we should stay with purpose and main and >>> presentation, or at the most, change it to content with main and >> slides >>> as did the IMTC SIP Parity WG for Role Based Video Streams. >> >> "Main" leaves me cold, to tell truth; "Presentation" may be >> marginally >> better than "slides" -- but I can't see this as worth revisiting. >> >> Whatever we do needs to be extensible, and "speaker" will likely >> deserve distinctions, not absorbtion into another content type. >> >> (For a few examples of where we may want to expand, consider > "panel" >> and "moderator"...) >> >>> My primary reason for wanting to define only main and presentation > (or >>> content attributes main and slides from the full list in RFC 4796) > is >>> similar to the reasoning from the SIP Parity WG - that in a > conference >>> It can easily create confusion and lack of non-interoperability - > for >>> example one system may use main and another speaker when referring > to >>> the same situation. >> >> I don't believe we can avoid such issues -- even if we were to > limit >> ourselves to only one allowed content-type. ;^) >> >> -- >> John Leslie > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From allyn@cisco.com Tue May 22 21:46:47 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FA7721F85ED for ; Tue, 22 May 2012 21:46:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YoTrl9188yUp for ; Tue, 22 May 2012 21:46:45 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 4F01621F85B5 for ; Tue, 22 May 2012 21:46:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=allyn@cisco.com; l=3899; q=dns/txt; s=iport; t=1337748396; x=1338957996; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=KhkFuKEqVeBtzSeXgnGiLr3TiH0RnLWdhf2P8L8qR+Y=; b=GkVgATv8mQe+VgoYQ/4YeRe54dUCWbkkLzBnb58mHR3FDGfcMQKdMK4o UQ8MOC9V4CbIfwB2lqzr82CBmCqd+GThW/Vm1N9NIW1MFSks3sqRUOMV4 NALcDCW+9/f9yE4Bo65vHDZRfJxbhJL6Dq/7ADleuYmUimpBCwr7ZJVif I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAAFrvE+rRDoH/2dsb2JhbABDDrQggQeCFQEBAQQBAQEPAR0KLgYXBAIBCA4DBAEBAQoGFwEGASYfCQgBAQQBEggah2sBC5sQn3UEiw4VhEliA4hDmmWBZIIxWYE3 X-IronPort-AV: E=Sophos;i="4.75,641,1330905600"; d="scan'208";a="43431215" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-3.cisco.com with ESMTP; 23 May 2012 04:46:36 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q4N4kZ2I025272; Wed, 23 May 2012 04:46:35 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); Tue, 22 May 2012 21:46:35 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 22 May 2012 21:46:34 -0700 Message-ID: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC078DE5B2@xmb-sjc-221.amer.cisco.com> In-Reply-To: <4FBC1C97.3070201@alum.mit.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] capture attributes - content attribute Thread-Index: Ac04b+7ep5uoGshFSwOKmAyxkUWFEQALs6Cw References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC0782890E@xmb-sjc-221.amer.cisco.com><20120522184220.GE2661@verdi><9AC2C4348FD86B4BB1F8FA9C5E3A5EDC07828954@xmb-sjc-221.amer.cisco.com> <4FBC1C97.3070201@alum.mit.edu> From: "Allyn Romanow (allyn)" To: "Paul Kyzivat" , X-OriginalArrivalTime: 23 May 2012 04:46:35.0748 (UTC) FILETIME=[0884AA40:01CD389F] Subject: Re: [clue] capture attributes - content attribute X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2012 04:46:47 -0000 Hi Paul, I'd like to just define the ones we have need for and leave definition of others for when there is a recognized need.=20 I don't have a real problem with doing what the SIP parity group did - restricting usage to slides (which seems odd for audio) and main. -----Original Message----- From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: Tuesday, May 22, 2012 4:09 PM To: clue@ietf.org Subject: Re: [clue] capture attributes - content attribute Allyn, I'd like to understand better what the problem was that you encountered. I guess you must have had a situation when one impl used "speaker" and=20 another used "main" for captures that were topologically and=20 semantically equivalent. I understand how that could be a problem. But=20 it seems like a problem that arises from insufficient definition of what the "purpose" values *mean*. That may mean we need to find a way to=20 supplement the definitions from 4976. In rooms where the arrangement is always a line of people facing a line=20 of screens and cameras there may not be a need for more than two=20 purposes. But other arrangements, such as ones that have a distinguished speaker/presenter, may need more. Thanks, Paul On 5/22/12 2:56 PM, Allyn Romanow (allyn) wrote: > Hi John, > My point wasn't really the name of the attributes, sorry if I expressed > it poorly. > > It was to not use the full list of RFC 4796 attributes, but to limit to > 2 of them... > OR, I even prefer just going back to purpose with main and > presentation.. but don't really object to content attributes if we sort > out ones that make sense to me. > >> -----Original Message----- >> From: John Leslie [mailto:john@jlc.net] >> Sent: Tuesday, May 22, 2012 11:42 AM >> To: Allyn Romanow (allyn) >> Cc: CLUE >> Subject: Re: [clue] capture attributes - content attribute >> >> Allyn Romanow (allyn) wrote: >>> >>> Earlier we changed the capture attribute "purpose" with values >>> presentation and main to content attribute taken from RFC 4976 with >>> content types slides, main, speaker, >>> >>> Initially, when this came up, I thought it was a simple change and > it >>> had the appeal of using an existing RFC, so I wasn't opposed to it. >>> However, in working on a proof of concept implementation, this > seemed >> to >>> have issues and I feel we should stay with purpose and main and >>> presentation, or at the most, change it to content with main and >> slides >>> as did the IMTC SIP Parity WG for Role Based Video Streams. >> >> "Main" leaves me cold, to tell truth; "Presentation" may be >> marginally >> better than "slides" -- but I can't see this as worth revisiting. >> >> Whatever we do needs to be extensible, and "speaker" will likely >> deserve distinctions, not absorbtion into another content type. >> >> (For a few examples of where we may want to expand, consider > "panel" >> and "moderator"...) >> >>> My primary reason for wanting to define only main and presentation > (or >>> content attributes main and slides from the full list in RFC 4796) > is >>> similar to the reasoning from the SIP Parity WG - that in a > conference >>> It can easily create confusion and lack of non-interoperability - > for >>> example one system may use main and another speaker when referring > to >>> the same situation. >> >> I don't believe we can avoid such issues -- even if we were to > limit >> ourselves to only one allowed content-type. ;^) >> >> -- >> John Leslie > _______________________________________________ > 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 From espeberg@cisco.com Wed May 23 07:36:29 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6038921F8726 for ; Wed, 23 May 2012 07:36:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.666 X-Spam-Level: X-Spam-Status: No, score=-9.666 tagged_above=-999 required=5 tests=[AWL=-0.933, BAYES_00=-2.599, FRT_LOLITA1=1.865, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9djOY5rrhhle for ; Wed, 23 May 2012 07:36:28 -0700 (PDT) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id C4F8621F871E for ; Wed, 23 May 2012 07:36:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=espeberg@cisco.com; l=3363; q=dns/txt; s=iport; t=1337783788; x=1338993388; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=+mJX9dK3p2KrTFICkbNgVCa33dV5FShBXRWmYeB0Jp4=; b=PBasml8WwQUgu/1xhsmUFFBsJ2eK985tKQuncDDCfrMwsmpSj4MBVZOY 36seUiZ5Eboc/gk/K6dc6jlGrXeMgq8Z9UFBbcJdim6PeI6zCb8XCL54u 7YD5HXVc8rTr8QRrqLmaOKyoMIuM+eYdniJ2TssyGBaic4faFLWxIhJD7 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAD70vE+Q/khN/2dsb2JhbABEtDSBB4IVAQEBBAEBAQ8BHT4XBAIBCBEEAQEBCgYXAQYBIAYfCQgBAQQBEggah14DCwuaR5YiDYlSiiFuJIQ6YgOIEI4biWiDFYFkgmw X-IronPort-AV: E=Sophos;i="4.75,645,1330905600"; d="scan'208";a="4877054" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-4.cisco.com with ESMTP; 23 May 2012 14:36:19 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q4NEaIjr022182; Wed, 23 May 2012 14:36:18 GMT Received: from xmb-ams-214.cisco.com ([144.254.75.25]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 23 May 2012 16:36:18 +0200 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: Wed, 23 May 2012 16:36:16 +0200 Message-ID: <92DF9533227FC14F946C7321074B8C9E01330A02@XMB-AMS-214.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] *Updated Consensus Call*: Add description text to a capturescene? Thread-Index: Ac04PdBjkuzB6zAvSE6RqlnHN6/vlgADRpnw References: From: "Espen Berger (espeberg)" To: "Mary Barnes" , "CLUE" X-OriginalArrivalTime: 23 May 2012 14:36:18.0120 (UTC) FILETIME=[6A0E2C80:01CD38F1] Subject: Re: [clue] *Updated Consensus Call*: Add description text to a capturescene? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2012 14:36:29 -0000 An optional descriptive text on individual captures might be useful. See = inline =20 -----Original Message----- From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of = Mary Barnes Sent: 22. mai 2012 10:11 To: CLUE Subject: [clue] *Updated Consensus Call*: Add description text to a = capturescene? Per Marshall's feedback, I am reposing the questions to consider the = optional aspect (which is what I think we have been discussing, but just = to be clear). 1) Do you agree that we should add a mandatory element with human = readable text to the capture scene? No 2) Do you agree that we should add an optional element with human = readable text to the capture scene? Yes 3) Do you agree that we should not add any optional or mandatory human = readable text to the capture scene? No Thanks, Mary. On Tue, May 22, 2012 at 11:36 AM, Mary Barnes = wrote: > Resending with a new Subject just to make sure folks pick up on this=20 > as a Consensus call. > > On Tue, May 22, 2012 at 11:35 AM, Mary Barnes=20 > > wrote: >> >> Hi all, >> >> Per the design team meeting this morning, we are doing a consensus=20 >> call on the question as to whether human readable text string should=20 >> be added to the capture scene. >> >> Note that while this came up during discussion of Ticket #8 in a=20 >> previous meeting, it does not impact the state of Ticket #8 which = remains open: >> http://trac.tools.ietf.org/wg/clue/trac/ticket/8 (How consumer=20 >> differentiates between multiple capture scenes) >> >> So, if folks could please respond to the following question with a = "Yes" >> or "No": >> >> Should a human readable text string be added to the capture scene in=20 >> the framework document? >> >> It would also be helpful (but not required for consensus) if folks=20 >> could provide a brief statement justifying their response for the WG=20 >> members that did not hear the discussion on today's call. >> >> The consensus call closes on Thursday at 5pm Pacific. >> >> Thanks, >> Mary >> CLUE WG co-chair >> >> >> >> >> On Fri, May 18, 2012 at 11:56 AM, Duckworth, Mark=20 >> wrote: >>> >>> Regarding Ticket #8 - How consumer differentiates between multiple=20 >>> capture scenes. >>> We discussed this a bit on the list, and on the April 10 phone = meeting. >>> =A0I think the group agreed we should add a human readable text = string=20 >>> attribute to a capture scene. >>> >>> Here is a proposal for adding text to the framework document section >>> 6.2.1 Capture scene attributes: >>> >>> Description attribute >>> >>> The description attribute is a human readable text string which=20 >>> describes the capture scene. =A0A provider that advertises multiple=20 >>> capture scenes may use different descriptions to differentiate = between them. >>> >>> >>> Do we also want to add a similar description attribute to a media=20 >>> capture? >>> >>> Mark Duckworth >>> _______________________________________________ >>> 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 From mary.ietf.barnes@gmail.com Wed May 23 08:36:09 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17A0421F86DA for ; Wed, 23 May 2012 08:36:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.599 X-Spam-Level: X-Spam-Status: No, score=-104.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_INVITATION=-2, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JMYtxvHrYHBu for ; Wed, 23 May 2012 08:36:08 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3740321F86EC for ; Wed, 23 May 2012 08:36:08 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so5672576vbb.31 for ; Wed, 23 May 2012 08:36:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=WLw/xGclFLimUDAOskp0cQvzYU45O/dVjR/7j6ZYGTE=; b=PRD81SOtxO8mljQc2b3i4XGSkCRIqkUyKAHWY++e3H3Sy0BaN+9od85RGvLRjUiMa4 5mZCsOL8R/5hkuJmJjilyrJx3qeQoUshCiE7JBhs1P/kVRQfmpNGBvjpxcPzvYn0l5Ug 73NcOWDVs6YvvQi+sLQmWV23mFI3LgB9/DsNf9/LCl0CbtgG3gwzoCHRB86poCmEmVvP gW88NviKki5ECtWgWcYCBJ66s5pjwqjtJ2ye7MRGA38EpXScb+qOe2zI2jD3gnNvqIhT ffazMV1GMMRYGnI8Z8EiYtiAmVl+cIJQ+H4nYRvTqXwW+nkW/+8W+Lpj4qLIAcVtaO3O tRdA== MIME-Version: 1.0 Received: by 10.220.156.10 with SMTP id u10mr3212763vcw.20.1337787367525; Wed, 23 May 2012 08:36:07 -0700 (PDT) Received: by 10.52.22.143 with HTTP; Wed, 23 May 2012 08:36:07 -0700 (PDT) In-Reply-To: <350256771.1337786909411.JavaMail.nobody@jva2wl003.webex.com> References: <350256771.1337786909411.JavaMail.nobody@jva2wl003.webex.com> Date: Wed, 23 May 2012 10:36:07 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: text/plain; charset=ISO-8859-1 Subject: [clue] Meeting invitation: CLUE WG Interim Meeting - June 7-8, 2012 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2012 15:36:09 -0000 Here's the Webex info fro the CLUE WG interim meeting. It will also be posted on the wiki: http://trac.tools.ietf.org/wg/clue/trac/wiki ---------- Forwarded message ---------- From: Clue Working Group Date: Wed, May 23, 2012 at 10:28 AM Subject: Meeting invitation: CLUE WG Interim Meeting - June 7-8, 2012 To: mary.ietf.barnes@gmail.com Hello , Clue Working Group invites you to attend this online meeting. Topic: CLUE WG Interim Meeting - June 7-8, 2012 Date: Every 1 day, from Thursday, June 7, 2012 to Friday, June 8, 2012 Time: 8:30 am, Sweden Summer Time (Stockholm, GMT+02:00) Meeting Number: 647 789 398 Meeting Password: 1234 ------------------------------------------------------- To join the online meeting (Now from mobile devices!) ------------------------------------------------------- 1. Go to https://ietf.webex.com/ietf/j.php?ED=154400817&UID=1252227252&PW=NNDg3NmE4NTM0&RT=MiMxMzA%3D 2. If requested, enter your name and email address. 3. If a password is required, enter the meeting password: 1234 4. Click "Join". To view in other time zones or languages, please click the link: https://ietf.webex.com/ietf/j.php?ED=154400817&UID=1252227252&PW=NNDg3NmE4NTM0&ORT=MiMxMzA%3D ------------------------------------------------------- To join the audio conference only ------------------------------------------------------- Call-in toll number (US/Canada): +1-408-600-3600 Access code:647 789 398 ------------------------------------------------------- For assistance ------------------------------------------------------- 1. Go to https://ietf.webex.com/ietf/mc 2. On the left navigation bar, click "Support". You can contact me at: clue-chairs@tools.ietf.org To add this meeting to your calendar program (for example Microsoft Outlook), click this link: https://ietf.webex.com/ietf/j.php?ED=154400817&UID=1252227252&ICS=MI&LD=1&RD=2&ST=1&SHA2=LQh88YtAZkWHDwPsSQ1myV2H9kHzLarE/1kVm6p/uXs=&RT=MiMxMzA%3D The playback of UCF (Universal Communications Format) rich media files requires appropriate players. To view this type of rich media files in the meeting, please check whether you have the players installed on your computer by going to https://ietf.webex.com/ietf/systemdiagnosis.php. Sign up for a free trial of WebEx http://www.webex.com/go/mcemfreetrial http://www.webex.com CCP:+14086003600x647789398# IMPORTANT NOTICE: This WebEx service includes a feature that allows audio and any documents and other materials exchanged or viewed during the session to be recorded. By joining this session, you automatically consent to such recordings. If you do not consent to the recording, discuss your concerns with the meeting host prior to the start of the recording or do not join the session. Please note that any such recordings may be subject to discovery in the event of litigation. From mary.ietf.barnes@gmail.com Wed May 23 08:58:56 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81DC621F86A4 for ; Wed, 23 May 2012 08:58:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.666 X-Spam-Level: X-Spam-Status: No, score=-103.666 tagged_above=-999 required=5 tests=[AWL=-0.066, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DZFbjXnr-2Rv for ; Wed, 23 May 2012 08:58:55 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 87A7821F8694 for ; Wed, 23 May 2012 08:58:55 -0700 (PDT) Received: by vcqp1 with SMTP id p1so1201852vcq.31 for ; Wed, 23 May 2012 08:58:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=WNxQiBjD0M1u9c0Tuv85hMq8W78iyht/eSxHFR4Vigo=; b=XRnqA9zx3WDWLNh4EZ25Qykofok3VNxSmlgVRuwe6FIiiv+KLdsGEw3XuXJaoUOPNI AJLkNynb0ncp0eAF45/z4Y5tUVGKHcMYt6KwXnzR0GzFb3Ot8xEhd2VfCX+UEErXmTiT cykfxbMQoDQkuLuCVqr1Wlf7jVyPb8np5S3FZzoWW5s/Wq12ySLDQrdbknjEilFylhRl jboY8Em1N080DxIzhwnK9Kyu4VYQcmk35svhQlNmW0Jj2Xl3YyLt44HtnJhO7oBR/MOl Egwt4+aIxEzw/f1XG04lNnIJsV728cCAwuFLtymRZ1mMlJoCdxsMNMPA+CP99TZj3HSN 3XAA== MIME-Version: 1.0 Received: by 10.220.242.6 with SMTP id lg6mr3311075vcb.18.1337788734775; Wed, 23 May 2012 08:58:54 -0700 (PDT) Received: by 10.52.22.143 with HTTP; Wed, 23 May 2012 08:58:54 -0700 (PDT) In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C457B1389@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05852C457B1389@ESESSCMS0356.eemea.ericsson.se> Date: Wed, 23 May 2012 10:58:54 -0500 Message-ID: From: Mary Barnes To: Christer Holmberg , Andy Pepperell Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: CLUE Subject: Re: [clue] Updates to CLUE information transport criteria from May 22 DT meeting X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2012 15:58:56 -0000 That would be great. The reason we discussed it on the call is that you had only received a couple responses on the mailing list. Per Allyn's response, it would be good if you could work with Andy on this, as well. If you and others that weren't at the meeting could please review the additions and clarifications that the folks on the call discussed, that would be extremely helpful. Also, we weren't clear on the intent of the last item (#8), so if you could please clarify that would be extremely helpful. Thanks, Mary. On Tue, May 22, 2012 at 3:11 PM, Christer Holmberg wrote: > Hi Mary, > > My intention is to start mapping the criterias to the data model. > > However, I'd first like us to have an understanding/agreement on what the= criterias are, and that's the reason I asked people to provide input on th= e list. > > Regards, > > Christer > > ________________________________________ > From: Mary Barnes [mary.ietf.barnes@gmail.com] > Sent: Tuesday, May 22, 2012 7:55 PM > To: CLUE > Cc: Christer Holmberg; Paul Kyzivat > Subject: Updates to CLUE information transport criteria from May 22 DT me= eting > > Hi all, > > This is a summary of updates proposed during today's design team > meeting, based on Christer's original proposal and Roni's suggested > additions: > http://www.ietf.org/mail-archive/web/clue/current/msg01433.html > > Note, this a very important thread of discussion as we really need > someone to step forward to take on detailing the data model and > evaluate each of the data elements against this criteria: > > 1) Whether signaling intermediaries (e.g. SBGs) need to have access to > =A0the information - i.e.. whether information is relevant to routing > decisions, policies as to how to route, etc. > > =A0-- Whether the CLUE information and the media description (SDP) need > to be in the same message. > > -- Whether the CLUE information and the media description (SDP) need > to use the same transport path. > > =A02) The expected size of the information to be sent (i.e., estimate of = bytes) > > =A03) The expected frequency of the information to be sent (i.e., 3 > categories, per earlier discussion...) > > =A04) Whether the information is sent during session establishment, mid- > session and/or session termination. > > -- Information for SIP session establishment > > -- Information about CLUE, information about media, information to > establish media > > =A05) What delay is acceptable for the information (i.e., CLUE data eleme= nt) > > 6) Whether the information is sent as a notification, or whether some > kind of response is needed > > -- Does information need to be carried in a request and response or > > -- is it just necessary to be communicated one way > > =A07) Whether the information needs to be delivered reliably (either > using =A0a reliable transport mechanism, and/or some kind of > higher-level =A0acknowledgement) > > 8) Whether the information is needed by a non-CLUE entity in order to > participate in a CLUE conference > > -- Not sure the intent here. Christer, can you please clarify what you > mean by non-CLUE. =A0Also, are you talking about some sort of mapping or > is this a more theoretical question? > > > > Thanks, > Mary. From mary.ietf.barnes@gmail.com Wed May 23 09:48:45 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B26221F8648 for ; Wed, 23 May 2012 09:48:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.661 X-Spam-Level: X-Spam-Status: No, score=-103.661 tagged_above=-999 required=5 tests=[AWL=-0.062, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YUKJCiP5MfYZ for ; Wed, 23 May 2012 09:48:44 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4188821F862B for ; Wed, 23 May 2012 09:48:44 -0700 (PDT) Received: by vcqp1 with SMTP id p1so1237000vcq.31 for ; Wed, 23 May 2012 09:48:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=fxrvI2QlpfKCRHO3ii6Awh4DYjVhMF7EAkV1TfjIK4s=; b=ZI0RhtLFVLJtpf136SsHCxl4aW0Ol1yx1fjcUKasepNj5edeFkqM8vRoXNiEFfBIW1 hQGLl0eJFXDBmpYYCgOlFF94MC8nAk8kMYC0vD+AYAtx/WDjIAo2OaCz4vQ7kHfIGDcC u9Oi2enPYYEYBGp8+Gla6iA/TEohoMDnde3bbR66KHzIVfKxTenv0XErR7kQtReIUhXs cfedX9RHn1rl4XUNHi3V6sPGHJ2H3nBKfUtXlpdLo4qrnuPE+xd77jPmChfRCS8VjfUH yNxGKZ0mKSwdZSuRsdDrMUhBe5WUtnYo8/XTV2iqIfq6MgTQDS5RaSJDmbJfkm3u3zOL RL6A== MIME-Version: 1.0 Received: by 10.52.28.71 with SMTP id z7mr12857312vdg.105.1337791723816; Wed, 23 May 2012 09:48:43 -0700 (PDT) Received: by 10.52.22.143 with HTTP; Wed, 23 May 2012 09:48:43 -0700 (PDT) In-Reply-To: References: Date: Wed, 23 May 2012 11:48:43 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [clue] Updates to CLUE information transport criteria from May 22 DT meeting X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2012 16:48:45 -0000 Per the thread on timing: http://www.ietf.org/mail-archive/web/clue/current/msg01346.html I have incorporated what I think were agreed in terms of the 3 categorizations that Marshall put forth in the item below. We would need to wordsmith the text to be specific to CLUE but I think the references to things like IPTV provide a useful reference/rationalization for the values. Ideally, if folks can provide any feedback no later than noon on Friday, May 25th, the folks doing the data model will have something to work from. Thanks, Mary. On Tue, May 22, 2012 at 11:55 AM, Mary Barnes wrote: > Hi all, > > This is a summary of updates proposed during today's design team > meeting, based on Christer's original proposal and Roni's suggested > additions: > http://www.ietf.org/mail-archive/web/clue/current/msg01433.html > > Note, this a very important thread of discussion as we really need > someone to step forward to take on detailing the data model and > evaluate each of the data elements against this criteria: > > 1) Whether signaling intermediaries (e.g. SBGs) need to have access to > =A0the information - i.e.. whether information is relevant to routing > decisions, policies as to how to route, etc. > > =A0-- Whether the CLUE information and the media description (SDP) need > to be in the same message. > > -- Whether the CLUE information and the media description (SDP) need > to use the same transport path. > > =A02) The expected size of the information to be sent (i.e., estimate of = bytes) > > =A03) The expected frequency of the information to be sent: -- 30 msec. This is a video frame. Nothing of significance can happen faster, and some things, such as video switching, ideally would only take one frame. -- 200 msec. This was always viewed as the ideal IPTV channel change time (and a lot of work was done on IGMP to try and get there). This also happens to be a rough upper bound on non-noticeable RTTs, and so is a rough limit on how fast you can do things if those things require some sort of RT handshake / authorization / acknowledgement. It would be good to do many CLUE config changes in this time range - experience is that users will tolerate 200 msec of interruption or dead time, if something major changes. -- many seconds. Setting up a conference, changing basic conference parameters, etc., can take many seconds. Rebooting equipment can take many seconds. > =A04) Whether the information is sent during session establishment, mid- > session and/or session termination. > > -- Information for SIP session establishment > > -- Information about CLUE, information about media, information to > establish media > > =A05) What delay is acceptable for the information (i.e., CLUE data eleme= nt) > > 6) Whether the information is sent as a notification, or whether some > kind of response is needed > > -- Does information need to be carried in a request and response or > > -- is it just necessary to be communicated one way > > =A07) Whether the information needs to be delivered reliably (either > using=A0 a reliable transport mechanism, and/or some kind of > higher-level=A0 acknowledgement) > > 8) Whether the information is needed by a non-CLUE entity in order to > participate in a CLUE conference > > -- Not sure the intent here. Christer, can you please clarify what you > mean by non-CLUE. =A0Also, are you talking about some sort of mapping or > is this a more theoretical question? > > > > Thanks, > Mary. From rohanse2@cisco.com Wed May 23 10:12:50 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 730BE21F86EF for ; Wed, 23 May 2012 10:12:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LyacJtV6NyGJ for ; Wed, 23 May 2012 10:12:49 -0700 (PDT) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id 9CDB521F86A3 for ; Wed, 23 May 2012 10:12:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rohanse2@cisco.com; l=400; q=dns/txt; s=iport; t=1337793169; x=1339002769; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=sy5cnskT3FNnJKHAPRZ5wTlq93qKMAzTfhvAljBcsls=; b=Ebewu8bzs2CfH28z8WdT2kMy5z/gth2uZ/UAZytFGXGsmv5piI2ftrW1 XFjM2iSSLkbAK8QG2XhioVWYf20Ukr4kC2blmKALe8XiAVr+0BgkIPMQy o8I4EbeDzUGMxNbbK74HNLqRvyFmDWSjAUTrY0TNe5yd2tt1y0Od2uQ1w c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjkMACQavU+Q/khN/2dsb2JhbABDgx2tRIIqAoEfgQeCFQEBAQMBEgElQAYLCxgJFg8JAwIBAgFFEwgBAR6HZgWbAZ91in13gRODFgOVGIVPiD2BZIJr X-IronPort-AV: E=Sophos;i="4.75,645,1330905600"; d="scan'208";a="4885279" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-4.cisco.com with ESMTP; 23 May 2012 17:12:47 +0000 Received: from [10.47.196.154] ([10.47.196.154]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q4NHClbh022587 for ; Wed, 23 May 2012 17:12:47 GMT Message-ID: <4FBD1A90.9070606@cisco.com> Date: Wed, 23 May 2012 18:12:48 +0100 From: Robert Hansen User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: clue@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] *Updated Consensus Call*: Add description text to a capture scene? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2012 17:12:50 -0000 On 22/05/2012 18:10, Mary Barnes wrote: > 1) Do you agree that we should add a mandatory element with human > readable text to the capture scene? No > 2) Do you agree that we should add an optional element with human > readable text to the capture scene? Yes > 3) Do you agree that we should not add any optional or mandatory human > readable text to the capture scene? No Rob From stewe@stewe.org Wed May 23 10:55:16 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C41521F853D for ; Wed, 23 May 2012 10:55:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[AWL=1.500, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EcXREGx2JKGT for ; Wed, 23 May 2012 10:55:15 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe002.messaging.microsoft.com [65.55.88.12]) by ietfa.amsl.com (Postfix) with ESMTP id B51A821F852C for ; Wed, 23 May 2012 10:55:15 -0700 (PDT) Received: from mail12-tx2-R.bigfish.com (10.9.14.243) by TX2EHSOBE006.bigfish.com (10.9.40.26) with Microsoft SMTP Server id 14.1.225.23; Wed, 23 May 2012 17:55:06 +0000 Received: from mail12-tx2 (localhost [127.0.0.1]) by mail12-tx2-R.bigfish.com (Postfix) with ESMTP id 734131A03B3; Wed, 23 May 2012 17:54:59 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.133; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0710HT002.namprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -29 X-BigFish: PS-29(zz9371I14ffI1432N98dK4015Izz1202h1082kzz1033IL8275bh8275dhz2fh2a8h668h839h944he5bhf0ah) Received-SPF: pass (mail12-tx2: domain of stewe.org designates 157.56.240.133 as permitted sender) client-ip=157.56.240.133; envelope-from=stewe@stewe.org; helo=BL2PRD0710HT002.namprd07.prod.outlook.com ; .outlook.com ; Received: from mail12-tx2 (localhost.localdomain [127.0.0.1]) by mail12-tx2 (MessageSwitch) id 1337795696909907_22381; Wed, 23 May 2012 17:54:56 +0000 (UTC) Received: from TX2EHSMHS038.bigfish.com (unknown [10.9.14.250]) by mail12-tx2.bigfish.com (Postfix) with ESMTP id D0F67140045; Wed, 23 May 2012 17:54:56 +0000 (UTC) Received: from BL2PRD0710HT002.namprd07.prod.outlook.com (157.56.240.133) by TX2EHSMHS038.bigfish.com (10.9.99.138) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 23 May 2012 17:55:03 +0000 Received: from BL2PRD0710MB349.namprd07.prod.outlook.com ([169.254.1.64]) by BL2PRD0710HT002.namprd07.prod.outlook.com ([10.255.102.37]) with mapi id 14.16.0164.004; Wed, 23 May 2012 17:55:05 +0000 From: Stephan Wenger To: Mary Barnes , CLUE Thread-Topic: [clue] *Updated Consensus Call*: Add description text to a capture scene? Thread-Index: AQHNOQ0v1dDtiBoLtkOA6iFsC8BihQ== Date: Wed, 23 May 2012 17:55:04 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.102.4] Content-Type: text/plain; charset="us-ascii" Content-ID: <1D0961BC09444040ADD82992B14FBB58@namprd07.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: stewe.org Subject: Re: [clue] *Updated Consensus Call*: Add description text to a capture scene? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2012 17:55:16 -0000 Sorry that I missed the call (again). On 5.22.2012 10:10 , "Mary Barnes" wrote: >Per Marshall's feedback, I am reposing the questions to consider the >optional aspect (which is what I think we have been discussing, but >just to be clear). > >1) Do you agree that we should add a mandatory element with human >readable text to the capture scene? No, because it's unenforcible to require something "human readable", and because it's unclear for what such a mandatory string would be needed. >2) Do you agree that we should add an optional element with human >readable text to the capture scene? Yes. >3) Do you agree that we should not add any optional or mandatory human >readable text to the capture scene? No. Looks like we are inching towards consensus on something. :-) Stephan > >Thanks, >Mary. > >On Tue, May 22, 2012 at 11:36 AM, Mary Barnes > wrote: >> Resending with a new Subject just to make sure folks pick up on this as >>a >> Consensus call. >> >> On Tue, May 22, 2012 at 11:35 AM, Mary Barnes >> >> wrote: >>> >>> Hi all, >>> >>> Per the design team meeting this morning, we are doing a consensus >>>call on >>> the question as to whether human readable text string should be added >>>to the >>> capture scene. >>> >>> Note that while this came up during discussion of Ticket #8 in a >>>previous >>> meeting, it does not impact the state of Ticket #8 which remains open: >>> http://trac.tools.ietf.org/wg/clue/trac/ticket/8 (How consumer >>> differentiates between multiple capture scenes) >>> >>> So, if folks could please respond to the following question with a >>>"Yes" >>> or "No": >>> >>> Should a human readable text string be added to the capture scene in >>>the >>> framework document? >>> >>> It would also be helpful (but not required for consensus) if folks >>>could >>> provide a brief statement justifying their response for the WG members >>>that >>> did not hear the discussion on today's call. >>> >>> The consensus call closes on Thursday at 5pm Pacific. >>> >>> Thanks, >>> Mary >>> CLUE WG co-chair >>> >>> >>> >>> >>> On Fri, May 18, 2012 at 11:56 AM, Duckworth, Mark >>> wrote: >>>> >>>> Regarding Ticket #8 - How consumer differentiates between multiple >>>> capture scenes. >>>> We discussed this a bit on the list, and on the April 10 phone >>>>meeting. >>>> I think the group agreed we should add a human readable text string >>>> attribute to a capture scene. >>>> >>>> Here is a proposal for adding text to the framework document section >>>> 6.2.1 Capture scene attributes: >>>> >>>> Description attribute >>>> >>>> The description attribute is a human readable text string which >>>>describes >>>> the capture scene. A provider that advertises multiple capture >>>>scenes may >>>> use different descriptions to differentiate between them. >>>> >>>> >>>> Do we also want to add a similar description attribute to a media >>>> capture? >>>> >>>> Mark Duckworth >>>> _______________________________________________ >>>> 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 From ron.even.tlv@gmail.com Wed May 23 14:28:45 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DED4E11E80CB for ; Wed, 23 May 2012 14:28:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.367 X-Spam-Level: X-Spam-Status: No, score=-3.367 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XBH6mXER-p1F for ; Wed, 23 May 2012 14:28:45 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 1166811E80C9 for ; Wed, 23 May 2012 14:28:44 -0700 (PDT) Received: by wibhn6 with SMTP id hn6so4247123wib.13 for ; Wed, 23 May 2012 14:28:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; 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; bh=oFw+kEqRl95Q4XU+n5DXHFLDwbfeVCnwhoBDph5ptQA=; b=FIo0vwVdTIN/IDXvzwIlk2HXl/2fBFvzMXvObw8BRhEevtjyONCaPScrOQgkhrvan1 ysqPJ4xhSKBHk+qM95chjH0iDKSQQDPWgJPFaXFzbvLiJxTbsc6VD/AwwCwWHIK9/9P8 SP6xRTlkeIYm9MPb6EB+oZi5cp9FwVspG7JY81mfShPPRy9oRe8u4u423AFKuIPXNfC3 xS5Vq2fJSi6sPlDZYAqpmfcpWJtyD49RUenwwAaNQWB7KPy8p1++O0h5sZxMi61gg8kp fu8tw3eDt4m2hugmnMbzXNDGu9c7kbpqMJxmSMJa7etMsLMlgKlZa9w6b630T7asMi1B 2eZw== Received: by 10.180.100.2 with SMTP id eu2mr17901478wib.10.1337808522246; Wed, 23 May 2012 14:28:42 -0700 (PDT) Received: from windows8d787f9 (bzq-79-177-198-116.red.bezeqint.net. [79.177.198.116]) by mx.google.com with ESMTPS id ez4sm42672650wid.3.2012.05.23.14.28.39 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 23 May 2012 14:28:40 -0700 (PDT) From: "Roni Even" To: "'Allyn Romanow \(allyn\)'" , "'John Leslie'" References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC0782890E@xmb-sjc-221.amer.cisco.com> <20120522184220.GE2661@verdi> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC07828954@xmb-sjc-221.amer.cisco.com> In-Reply-To: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC07828954@xmb-sjc-221.amer.cisco.com> Date: Thu, 24 May 2012 00:26:32 +0300 Message-ID: <4fbd5688.a40db50a.7cd8.37ad@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: Ac04Sqd+4FlQ45WHQAOezoiNFaY41AAAb7owADdV/FA= Content-Language: en-us Cc: 'CLUE' Subject: Re: [clue] capture attributes - content attribute X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2012 21:28:46 -0000 Hi Allyn, My understanding is that RFC 4796 defines an attribute that can be used to provide semantics to the stream. Yet in order to have interoperability there need to be a specific profile that will describe the behavior expected when a specific content value is offered. An example is using the presentation and main in "H.239" like SIP usage. The framework needs to recommend the values that will be used for the room "main" and for the presentation. (personally I do not like the name slides) and how to interoperate when they are received. As for the rest, if we have usage we will need to specify how to use them in CLUE applications. Roni > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Allyn Romanow (allyn) > Sent: Tuesday, May 22, 2012 9:57 PM > To: John Leslie > Cc: CLUE > Subject: Re: [clue] capture attributes - content attribute > > Hi John, > My point wasn't really the name of the attributes, sorry if I expressed > it poorly. > > It was to not use the full list of RFC 4796 attributes, but to limit to > 2 of them... > OR, I even prefer just going back to purpose with main and > presentation.. but don't really object to content attributes if we sort > out ones that make sense to me. > > > -----Original Message----- > > From: John Leslie [mailto:john@jlc.net] > > Sent: Tuesday, May 22, 2012 11:42 AM > > To: Allyn Romanow (allyn) > > Cc: CLUE > > Subject: Re: [clue] capture attributes - content attribute > > > > Allyn Romanow (allyn) wrote: > > > > > > Earlier we changed the capture attribute "purpose" with values > > > presentation and main to content attribute taken from RFC 4976 with > > > content types slides, main, speaker, > > > > > > Initially, when this came up, I thought it was a simple change and > it > > > had the appeal of using an existing RFC, so I wasn't opposed to it. > > > However, in working on a proof of concept implementation, this > seemed > > to > > > have issues and I feel we should stay with purpose and main and > > > presentation, or at the most, change it to content with main and > > slides > > > as did the IMTC SIP Parity WG for Role Based Video Streams. > > > > "Main" leaves me cold, to tell truth; "Presentation" may be > > marginally better than "slides" -- but I can't see this as worth > > revisiting. > > > > Whatever we do needs to be extensible, and "speaker" will likely > > deserve distinctions, not absorbtion into another content type. > > > > (For a few examples of where we may want to expand, consider > "panel" > > and "moderator"...) > > > > > My primary reason for wanting to define only main and presentation > (or > > > content attributes main and slides from the full list in RFC 4796) > is > > > similar to the reasoning from the SIP Parity WG - that in a > conference > > > It can easily create confusion and lack of non-interoperability - > for > > > example one system may use main and another speaker when referring > to > > > the same situation. > > > > I don't believe we can avoid such issues -- even if we were to > limit > > ourselves to only one allowed content-type. ;^) > > > > -- > > John Leslie > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From ron.even.tlv@gmail.com Wed May 23 14:33:24 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0357011E8098 for ; Wed, 23 May 2012 14:33:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.388 X-Spam-Level: X-Spam-Status: No, score=-3.388 tagged_above=-999 required=5 tests=[AWL=0.211, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JEkgTq6S9jUW for ; Wed, 23 May 2012 14:33:23 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1C19E11E8080 for ; Wed, 23 May 2012 14:33:22 -0700 (PDT) Received: by wibhj8 with SMTP id hj8so4183374wib.13 for ; Wed, 23 May 2012 14:33:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language; bh=x8nUG7OdrSaH4XtR11DOle0hHwYSG+mJQGvAOmCcNHM=; b=AAC26aQ2xLx3OeyrgSxnI7uF9qbNrFJSW1bzY/dWeOxQWRR8JI3MHETNXxMorm9/1j m9j+Wrsi7u1UZ3581zbFOV4auuiZepGZbfXG1aoh+2A7/FVI6jVMR1mvcVUEv/iLRhHu MsSrwuGhGN6a338IwJVdPq0x2u/fH9cO+TBCDAe7zy0atb3+sXO5fWXRv7jmtjqJRgty I1gGLCMKfv6FwOO/tyxGRe8iv2EfObm60ulodCml351MBajFuGvXBRz0aCpMXJ2B+tRa MYyymEuvB1oKeE37VB9A+fxXo8Pqu6imp3lGhEDPTHogMpTsyFVvCR1Iq9jDpKfnJ+kI wJpg== Received: by 10.180.101.103 with SMTP id ff7mr49687423wib.6.1337808801937; Wed, 23 May 2012 14:33:21 -0700 (PDT) Received: from windows8d787f9 (bzq-79-177-198-116.red.bezeqint.net. [79.177.198.116]) by mx.google.com with ESMTPS id n11sm529315wiv.9.2012.05.23.14.33.19 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 23 May 2012 14:33:20 -0700 (PDT) From: "Roni Even" To: "'Mary Barnes'" , "'CLUE'" References: In-Reply-To: Date: Thu, 24 May 2012 00:31:12 +0300 Message-ID: <4fbd57a0.cb49b40a.4fcd.1039@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac04Pc5dz8t+VOseQWaBHVI/+mMuugA7SAsQ Content-Language: en-us Subject: Re: [clue] *Updated Consensus Call*: Add description text to a capture scene? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2012 21:33:24 -0000 Hi 1. No 2. Yes 3. no This human readable text must support Multilanguage. Roni Even > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf = Of > Mary Barnes > Sent: Tuesday, May 22, 2012 8:11 PM > To: CLUE > Subject: [clue] *Updated Consensus Call*: Add description text to a > capture scene? >=20 > Per Marshall's feedback, I am reposing the questions to consider the > optional aspect (which is what I think we have been discussing, but > just to be clear). >=20 > 1) Do you agree that we should add a mandatory element with human > readable text to the capture scene? > 2) Do you agree that we should add an optional element with human > readable text to the capture scene? > 3) Do you agree that we should not add any optional or mandatory human > readable text to the capture scene? >=20 > Thanks, > Mary. >=20 > On Tue, May 22, 2012 at 11:36 AM, Mary Barnes > wrote: > > Resending with a new Subject just to make sure folks pick up on this > > as a Consensus call. > > > > On Tue, May 22, 2012 at 11:35 AM, Mary Barnes > > > > wrote: > >> > >> Hi all, > >> > >> Per the design team meeting this morning, we are doing a consensus > >> call on the question as to whether human readable text string = should > >> be added to the capture scene. > >> > >> Note that while this came up during discussion of Ticket #8 in a > >> previous meeting, it does not impact the state of Ticket #8 which > remains open: > >> http://trac.tools.ietf.org/wg/clue/trac/ticket/8 (How consumer > >> differentiates between multiple capture scenes) > >> > >> So, if folks could please respond to the following question with a > "Yes" > >> or "No": > >> > >> Should a human readable text string be added to the capture scene = in > >> the framework document? > >> > >> It would also be helpful (but not required for consensus) if folks > >> could provide a brief statement justifying their response for the = WG > >> members that did not hear the discussion on today's call. > >> > >> The consensus call closes on Thursday at 5pm Pacific. > >> > >> Thanks, > >> Mary > >> CLUE WG co-chair > >> > >> > >> > >> > >> On Fri, May 18, 2012 at 11:56 AM, Duckworth, Mark > >> wrote: > >>> > >>> Regarding Ticket #8 - How consumer differentiates between multiple > >>> capture scenes. > >>> We discussed this a bit on the list, and on the April 10 phone > meeting. > >>> =A0I think the group agreed we should add a human readable text > string > >>> attribute to a capture scene. > >>> > >>> Here is a proposal for adding text to the framework document > section > >>> 6.2.1 Capture scene attributes: > >>> > >>> Description attribute > >>> > >>> The description attribute is a human readable text string which > >>> describes the capture scene. =A0A provider that advertises = multiple > >>> capture scenes may use different descriptions to differentiate > between them. > >>> > >>> > >>> Do we also want to add a similar description attribute to a media > >>> capture? > >>> > >>> Mark Duckworth > >>> _______________________________________________ > >>> 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 From allyn@cisco.com Wed May 23 14:44:44 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E89FE21F8555 for ; Wed, 23 May 2012 14:44:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mnDto8FBhalJ for ; Wed, 23 May 2012 14:44:44 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 5686C21F8552 for ; Wed, 23 May 2012 14:44:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=allyn@cisco.com; l=4261; q=dns/txt; s=iport; t=1337809484; x=1339019084; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=LgK5OPA30PT7jJKZjts/pD38I536HR1cuGmty3e1W/0=; b=I6pO0ukPYLsCgmke7pNIfdjTjrqpb2PpsdZ0bycAAAkh5u5ijslOGUL5 aflN4i4CkPwnN2MG5TKqtVJ3xXGnNbUvNiYij6dEQSlNBh+rj7NlfmFQd cusgZKaIU5S3XrYKnrNoJ7ITQfIIjyDUdyGSc8dBtrNekVAJJimxIBpop Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFACFavU+rRDoJ/2dsb2JhbABDtC2BB4IVAQEBBAEBAQ8BHQouBgsMBAIBCA4DBAEBAQoGFwEGASAGHwkIAQEEARIIGoddAwoBC5shlhgNiUoEihxhFYQrYAOIP5dQgxWBZIMKgTc X-IronPort-AV: E=Sophos;i="4.75,646,1330905600"; d="scan'208";a="46142108" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 23 May 2012 21:44:42 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q4NLifbx012741; Wed, 23 May 2012 21:44:41 GMT Received: from xmb-sjc-221.amer.cisco.com ([128.107.191.80]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 23 May 2012 14:44:41 -0700 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: Wed, 23 May 2012 14:44:33 -0700 Message-ID: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC078DE88D@xmb-sjc-221.amer.cisco.com> In-Reply-To: <4fbd5688.a40db50a.7cd8.37ad@mx.google.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] capture attributes - content attribute Thread-Index: Ac04Sqd+4FlQ45WHQAOezoiNFaY41AAAb7owADdV/FAAALWBUA== References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC0782890E@xmb-sjc-221.amer.cisco.com> <20120522184220.GE2661@verdi> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC07828954@xmb-sjc-221.amer.cisco.com> <4fbd5688.a40db50a.7cd8.37ad@mx.google.com> From: "Allyn Romanow (allyn)" To: "Roni Even" , "John Leslie" X-OriginalArrivalTime: 23 May 2012 21:44:41.0721 (UTC) FILETIME=[42986E90:01CD392D] Cc: CLUE Subject: Re: [clue] capture attributes - content attribute X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2012 21:44:45 -0000 Hi Roni, Sounds good to me... Couple of questions of clarification- What values do you think we might have for main and presentation? I took them to be the values of "purpose" or content. And, do you think we will have a profile that describes behavior expected when a content value is offered-beyond what is in the framework doc? thanks > -----Original Message----- > From: Roni Even [mailto:ron.even.tlv@gmail.com] > Sent: Wednesday, May 23, 2012 2:27 PM > To: Allyn Romanow (allyn); 'John Leslie' > Cc: 'CLUE' > Subject: RE: [clue] capture attributes - content attribute >=20 > Hi Allyn, > My understanding is that RFC 4796 defines an attribute that can be used > to > provide semantics to the stream. Yet in order to have interoperability > there > need to be a specific profile that will describe the behavior expected > when > a specific content value is offered. An example is using the > presentation > and main in "H.239" like SIP usage. >=20 > The framework needs to recommend the values that will be used for the > room > "main" and for the presentation. (personally I do not like the name > slides) > and how to interoperate when they are received. As for the rest, if we > have > usage we will need to specify how to use them in CLUE applications. >=20 > Roni >=20 > > -----Original Message----- > > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf > Of > > Allyn Romanow (allyn) > > Sent: Tuesday, May 22, 2012 9:57 PM > > To: John Leslie > > Cc: CLUE > > Subject: Re: [clue] capture attributes - content attribute > > > > Hi John, > > My point wasn't really the name of the attributes, sorry if I > expressed > > it poorly. > > > > It was to not use the full list of RFC 4796 attributes, but to limit > to > > 2 of them... > > OR, I even prefer just going back to purpose with main and > > presentation.. but don't really object to content attributes if we > sort > > out ones that make sense to me. > > > > > -----Original Message----- > > > From: John Leslie [mailto:john@jlc.net] > > > Sent: Tuesday, May 22, 2012 11:42 AM > > > To: Allyn Romanow (allyn) > > > Cc: CLUE > > > Subject: Re: [clue] capture attributes - content attribute > > > > > > Allyn Romanow (allyn) wrote: > > > > > > > > Earlier we changed the capture attribute "purpose" with values > > > > presentation and main to content attribute taken from RFC 4976 > with > > > > content types slides, main, speaker, > > > > > > > > Initially, when this came up, I thought it was a simple change > and > > it > > > > had the appeal of using an existing RFC, so I wasn't opposed to > it. > > > > However, in working on a proof of concept implementation, this > > seemed > > > to > > > > have issues and I feel we should stay with purpose and main and > > > > presentation, or at the most, change it to content with main and > > > slides > > > > as did the IMTC SIP Parity WG for Role Based Video Streams. > > > > > > "Main" leaves me cold, to tell truth; "Presentation" may be > > > marginally better than "slides" -- but I can't see this as worth > > > revisiting. > > > > > > Whatever we do needs to be extensible, and "speaker" will likely > > > deserve distinctions, not absorbtion into another content type. > > > > > > (For a few examples of where we may want to expand, consider > > "panel" > > > and "moderator"...) > > > > > > > My primary reason for wanting to define only main and presentation > > (or > > > > content attributes main and slides from the full list in RFC 4796) > > is > > > > similar to the reasoning from the SIP Parity WG - that in a > > conference > > > > It can easily create confusion and lack of non-interoperability - > > for > > > > example one system may use main and another speaker when referring > > to > > > > the same situation. > > > > > > I don't believe we can avoid such issues -- even if we were to > > limit > > > ourselves to only one allowed content-type. ;^) > > > > > > -- > > > John Leslie > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue From ron.even.tlv@gmail.com Wed May 23 14:51:46 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0253221F85D7 for ; Wed, 23 May 2012 14:51:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.406 X-Spam-Level: X-Spam-Status: No, score=-3.406 tagged_above=-999 required=5 tests=[AWL=0.193, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yQB0qIxWP3m6 for ; Wed, 23 May 2012 14:51:45 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id D235721F85A2 for ; Wed, 23 May 2012 14:51:44 -0700 (PDT) Received: by wibhn6 with SMTP id hn6so4260779wib.13 for ; Wed, 23 May 2012 14:51:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; 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; bh=go+TEm98Elbl5p+I4779IhaPxFpTDwgjSa2IyexW3X0=; b=e3r4mUal0rfu6JhlPlGYCyJsmPnP9dvb2VvGLzonTtZg3ONiHcd2+ZXcNcrcnRid5Q 9NeigiwpAoY01J2St1IHPoPJbwQZXt4H4He03LYYbNLRspzlut+mofGUDh2s5mI7h6NC W+Svcv0RLRzhNnLOAD58PY+6LlW5/wKZ+HTVTMmaiWUq4rhCNfu4oFBwyCWlyCE3eGgx RR0XdZldiSrxYAggfSt6m14nStBmmF+a2kgDbA8MvgTFrfIb+yo6x5Sm4+r8p4b+xFKb hfPNR8faVEmny6cAMHLdx2sNlYHxy1y31KT/hJc+WgUOk/MvtDDDeFBe3mmBSzmhETzY bslA== Received: by 10.216.131.223 with SMTP id m73mr298340wei.76.1337809903911; Wed, 23 May 2012 14:51:43 -0700 (PDT) Received: from windows8d787f9 (bzq-79-177-198-116.red.bezeqint.net. [79.177.198.116]) by mx.google.com with ESMTPS id eb8sm42898304wib.11.2012.05.23.14.51.41 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 23 May 2012 14:51:42 -0700 (PDT) From: "Roni Even" To: "'Allyn Romanow \(allyn\)'" , "'John Leslie'" References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC0782890E@xmb-sjc-221.amer.cisco.com> <20120522184220.GE2661@verdi> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC07828954@xmb-sjc-221.amer.cisco.com> <4fbd5688.a40db50a.7cd8.37ad@mx.google.com> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC078DE88D@xmb-sjc-221.amer.cisco.com> In-Reply-To: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC078DE88D@xmb-sjc-221.amer.cisco.com> Date: Thu, 24 May 2012 00:49:34 +0300 Message-ID: <4fbd5bee.a861b40a.3862.3fd1@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: Ac04Sqd+4FlQ45WHQAOezoiNFaY41AAAb7owADdV/FAAALWBUAAAKusA Content-Language: en-us Cc: 'CLUE' Subject: Re: [clue] capture attributes - content attribute X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2012 21:51:46 -0000 Hi Allyn, I see no problem for the "main" value if we say this is the capture scene of the TP room. As for presentation or slides I think that it will be good to clarify if we want an H.239 like behavior or if it is just a presentation conveyed as a video stream without any token. If we want the first one it will be good if Charles can look at having a document we can reference here (publically available). Roni > -----Original Message----- > From: Allyn Romanow (allyn) [mailto:allyn@cisco.com] > Sent: Thursday, May 24, 2012 12:45 AM > To: Roni Even; John Leslie > Cc: CLUE > Subject: RE: [clue] capture attributes - content attribute > > Hi Roni, > Sounds good to me... > > Couple of questions of clarification- > What values do you think we might have for main and presentation? I > took them to be the values of "purpose" or content. > > And, do you think we will have a profile that describes behavior > expected when a content value is offered-beyond what is in the > framework doc? > > thanks > > > -----Original Message----- > > From: Roni Even [mailto:ron.even.tlv@gmail.com] > > Sent: Wednesday, May 23, 2012 2:27 PM > > To: Allyn Romanow (allyn); 'John Leslie' > > Cc: 'CLUE' > > Subject: RE: [clue] capture attributes - content attribute > > > > Hi Allyn, > > My understanding is that RFC 4796 defines an attribute that can be > used > > to > > provide semantics to the stream. Yet in order to have > interoperability > > there need to be a specific profile that will describe the behavior > > expected when a specific content value is offered. An example is > using > > the presentation and main in "H.239" like SIP usage. > > > > The framework needs to recommend the values that will be used for the > > room "main" and for the presentation. (personally I do not like the > > name > > slides) > > and how to interoperate when they are received. As for the rest, if > we > > have usage we will need to specify how to use them in CLUE > > applications. > > > > Roni > > > > > -----Original Message----- > > > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On > Behalf > > Of > > > Allyn Romanow (allyn) > > > Sent: Tuesday, May 22, 2012 9:57 PM > > > To: John Leslie > > > Cc: CLUE > > > Subject: Re: [clue] capture attributes - content attribute > > > > > > Hi John, > > > My point wasn't really the name of the attributes, sorry if I > > expressed > > > it poorly. > > > > > > It was to not use the full list of RFC 4796 attributes, but to > limit > > to > > > 2 of them... > > > OR, I even prefer just going back to purpose with main and > > > presentation.. but don't really object to content attributes if we > > sort > > > out ones that make sense to me. > > > > > > > -----Original Message----- > > > > From: John Leslie [mailto:john@jlc.net] > > > > Sent: Tuesday, May 22, 2012 11:42 AM > > > > To: Allyn Romanow (allyn) > > > > Cc: CLUE > > > > Subject: Re: [clue] capture attributes - content attribute > > > > > > > > Allyn Romanow (allyn) wrote: > > > > > > > > > > Earlier we changed the capture attribute "purpose" with values > > > > > presentation and main to content attribute taken from RFC 4976 > > with > > > > > content types slides, main, speaker, > > > > > > > > > > Initially, when this came up, I thought it was a simple change > > and > > > it > > > > > had the appeal of using an existing RFC, so I wasn't opposed to > > it. > > > > > However, in working on a proof of concept implementation, this > > > seemed > > > > to > > > > > have issues and I feel we should stay with purpose and main > and > > > > > presentation, or at the most, change it to content with main > and > > > > slides > > > > > as did the IMTC SIP Parity WG for Role Based Video Streams. > > > > > > > > "Main" leaves me cold, to tell truth; "Presentation" may be > > > > marginally better than "slides" -- but I can't see this as worth > > > > revisiting. > > > > > > > > Whatever we do needs to be extensible, and "speaker" will > likely > > > > deserve distinctions, not absorbtion into another content type. > > > > > > > > (For a few examples of where we may want to expand, consider > > > "panel" > > > > and "moderator"...) > > > > > > > > > My primary reason for wanting to define only main and > presentation > > > (or > > > > > content attributes main and slides from the full list in RFC > 4796) > > > is > > > > > similar to the reasoning from the SIP Parity WG - that in a > > > conference > > > > > It can easily create confusion and lack of non- > interoperability > - > > > for > > > > > example one system may use main and another speaker when > referring > > > to > > > > > the same situation. > > > > > > > > I don't believe we can avoid such issues -- even if we were to > > > limit > > > > ourselves to only one allowed content-type. ;^) > > > > > > > > -- > > > > John Leslie > > > _______________________________________________ > > > clue mailing list > > > clue@ietf.org > > > https://www.ietf.org/mailman/listinfo/clue From pkyzivat@alum.mit.edu Wed May 23 15:59:53 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 926CA21F84D6 for ; Wed, 23 May 2012 15:59:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.717 X-Spam-Level: X-Spam-Status: No, score=-2.717 tagged_above=-999 required=5 tests=[AWL=-0.118, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iqLQk79mWqvP for ; Wed, 23 May 2012 15:59:53 -0700 (PDT) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [76.96.59.243]) by ietfa.amsl.com (Postfix) with ESMTP id 109B521F84CF for ; Wed, 23 May 2012 15:59:52 -0700 (PDT) Received: from omta11.westchester.pa.mail.comcast.net ([76.96.62.36]) by qmta13.westchester.pa.mail.comcast.net with comcast id Dasl1j0010mv7h05Dazs2s; Wed, 23 May 2012 22:59:52 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta11.westchester.pa.mail.comcast.net with comcast id Dazs1j00E07duvL3XazsC0; Wed, 23 May 2012 22:59:52 +0000 Message-ID: <4FBD6BE7.7020502@alum.mit.edu> Date: Wed, 23 May 2012 18:59:51 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: clue@ietf.org References: <4fbd57a0.cb49b40a.4fcd.1039@mx.google.com> In-Reply-To: <4fbd57a0.cb49b40a.4fcd.1039@mx.google.com> Content-Type: text/plain; charset=windows-1255; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] *Updated Consensus Call*: Add description text to a capture scene? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2012 22:59:53 -0000 On 5/23/12 5:31 PM, Roni Even wrote: > This human readable text must support Multilanguage. Good point! Do you think we need provision for versions in multiple languages? Thanks, Paul From pkyzivat@alum.mit.edu Wed May 23 16:06:29 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23D4521F85FC for ; Wed, 23 May 2012 16:06:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.707 X-Spam-Level: X-Spam-Status: No, score=-2.707 tagged_above=-999 required=5 tests=[AWL=-0.108, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kF1Lll2G1SHR for ; Wed, 23 May 2012 16:06:28 -0700 (PDT) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [76.96.59.243]) by ietfa.amsl.com (Postfix) with ESMTP id 2860F21F8589 for ; Wed, 23 May 2012 16:06:27 -0700 (PDT) Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta13.westchester.pa.mail.comcast.net with comcast id DX3a1j0041swQuc5Db6S8f; Wed, 23 May 2012 23:06:26 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta15.westchester.pa.mail.comcast.net with comcast id Db6S1j00c07duvL3bb6Sp0; Wed, 23 May 2012 23:06:26 +0000 Message-ID: <4FBD6D71.7010300@alum.mit.edu> Date: Wed, 23 May 2012 19:06:25 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: clue@ietf.org References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC0782890E@xmb-sjc-221.amer.cisco.com> <20120522184220.GE2661@verdi> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC07828954@xmb-sjc-221.amer.cisco.com> <4fbd5688.a40db50a.7cd8.37ad@mx.google.com> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC078DE88D@xmb-sjc-221.amer.cisco.com> <4fbd5bee.a861b40a.3862.3fd1@mx.google.com> In-Reply-To: <4fbd5bee.a861b40a.3862.3fd1@mx.google.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] capture attributes - content attribute X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2012 23:06:29 -0000 On 5/23/12 5:49 PM, Roni Even wrote: > Hi Allyn, > I see no problem for the "main" value if we say this is the capture scene of > the TP room. As for presentation or slides I think that it will be good to > clarify if we want an H.239 like behavior or if it is just a presentation > conveyed as a video stream without any token. If we want the first one it > will be good if Charles can look at having a document we can reference here > (publically available). There has been frequent discussion of deferring to BFCP for the things it does. It has floor control. So I've been assuming that explicit floor control for presentations ('slides') would be that way. It will no doubt take some work to specify how CLUE and BFCP cooperate. Were you thinking we would use something else? Thanks, Paul > Roni > >> -----Original Message----- >> From: Allyn Romanow (allyn) [mailto:allyn@cisco.com] >> Sent: Thursday, May 24, 2012 12:45 AM >> To: Roni Even; John Leslie >> Cc: CLUE >> Subject: RE: [clue] capture attributes - content attribute >> >> Hi Roni, >> Sounds good to me... >> >> Couple of questions of clarification- >> What values do you think we might have for main and presentation? I >> took them to be the values of "purpose" or content. >> >> And, do you think we will have a profile that describes behavior >> expected when a content value is offered-beyond what is in the >> framework doc? >> >> thanks >> >>> -----Original Message----- >>> From: Roni Even [mailto:ron.even.tlv@gmail.com] >>> Sent: Wednesday, May 23, 2012 2:27 PM >>> To: Allyn Romanow (allyn); 'John Leslie' >>> Cc: 'CLUE' >>> Subject: RE: [clue] capture attributes - content attribute >>> >>> Hi Allyn, >>> My understanding is that RFC 4796 defines an attribute that can be >> used >>> to >>> provide semantics to the stream. Yet in order to have >> interoperability >>> there need to be a specific profile that will describe the behavior >>> expected when a specific content value is offered. An example is >> using >>> the presentation and main in "H.239" like SIP usage. >>> >>> The framework needs to recommend the values that will be used for the >>> room "main" and for the presentation. (personally I do not like the >>> name >>> slides) >>> and how to interoperate when they are received. As for the rest, if >> we >>> have usage we will need to specify how to use them in CLUE >>> applications. >>> >>> Roni >>> >>>> -----Original Message----- >>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On >> Behalf >>> Of >>>> Allyn Romanow (allyn) >>>> Sent: Tuesday, May 22, 2012 9:57 PM >>>> To: John Leslie >>>> Cc: CLUE >>>> Subject: Re: [clue] capture attributes - content attribute >>>> >>>> Hi John, >>>> My point wasn't really the name of the attributes, sorry if I >>> expressed >>>> it poorly. >>>> >>>> It was to not use the full list of RFC 4796 attributes, but to >> limit >>> to >>>> 2 of them... >>>> OR, I even prefer just going back to purpose with main and >>>> presentation.. but don't really object to content attributes if we >>> sort >>>> out ones that make sense to me. >>>> >>>>> -----Original Message----- >>>>> From: John Leslie [mailto:john@jlc.net] >>>>> Sent: Tuesday, May 22, 2012 11:42 AM >>>>> To: Allyn Romanow (allyn) >>>>> Cc: CLUE >>>>> Subject: Re: [clue] capture attributes - content attribute >>>>> >>>>> Allyn Romanow (allyn) wrote: >>>>>> >>>>>> Earlier we changed the capture attribute "purpose" with values >>>>>> presentation and main to content attribute taken from RFC 4976 >>> with >>>>>> content types slides, main, speaker, >>>>>> >>>>>> Initially, when this came up, I thought it was a simple change >>> and >>>> it >>>>>> had the appeal of using an existing RFC, so I wasn't opposed to >>> it. >>>>>> However, in working on a proof of concept implementation, this >>>> seemed >>>>> to >>>>>> have issues and I feel we should stay with purpose and main >> and >>>>>> presentation, or at the most, change it to content with main >> and >>>>> slides >>>>>> as did the IMTC SIP Parity WG for Role Based Video Streams. >>>>> >>>>> "Main" leaves me cold, to tell truth; "Presentation" may be >>>>> marginally better than "slides" -- but I can't see this as worth >>>>> revisiting. >>>>> >>>>> Whatever we do needs to be extensible, and "speaker" will >> likely >>>>> deserve distinctions, not absorbtion into another content type. >>>>> >>>>> (For a few examples of where we may want to expand, consider >>>> "panel" >>>>> and "moderator"...) >>>>> >>>>>> My primary reason for wanting to define only main and >> presentation >>>> (or >>>>>> content attributes main and slides from the full list in RFC >> 4796) >>>> is >>>>>> similar to the reasoning from the SIP Parity WG - that in a >>>> conference >>>>>> It can easily create confusion and lack of non- >> interoperability >> - >>>> for >>>>>> example one system may use main and another speaker when >> referring >>>> to >>>>>> the same situation. >>>>> >>>>> I don't believe we can avoid such issues -- even if we were to >>>> limit >>>>> ourselves to only one allowed content-type. ;^) >>>>> >>>>> -- >>>>> John Leslie >>>> _______________________________________________ >>>> 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 > From Mark.Duckworth@polycom.com Wed May 23 18:14:04 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C5B111E80AC for ; Wed, 23 May 2012 18:14:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JpMl5Vq1ctjD for ; Wed, 23 May 2012 18:14:04 -0700 (PDT) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 0E97411E80AB for ; Wed, 23 May 2012 18:14:03 -0700 (PDT) Received: from Crpmboxprd01.polycom.com ([fe80::ad68:5a0:c919:66b6]) by crpehubprd02.polycom.com ([fe80::5efe:10.236.0.154%12]) with mapi; Wed, 23 May 2012 18:14:03 -0700 From: "Duckworth, Mark" To: CLUE Date: Wed, 23 May 2012 18:14:01 -0700 Thread-Topic: *Updated Consensus Call*: Add description text to a capture scene? Thread-Index: Ac04PdEiEKRLr+GiTUaadBf4ChhFFQBDGXLg Message-ID: <44C6B6B2D0CF424AA90B6055548D7A6102FD969CDB@CRPMBOXPRD01.polycom.com> References: 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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [clue] *Updated Consensus Call*: Add description text to a capture scene? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 24 May 2012 01:14:04 -0000 > 1) Do you agree that we should add a mandatory element with human > readable text to the capture scene? No. =20 > 2) Do you agree that we should add an optional element with human > readable text to the capture scene? Yes. > 3) Do you agree that we should not add any optional or mandatory human > readable text to the capture scene? No. Mark From Christian.Groves@nteczone.com Wed May 23 22:16:31 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B80D21F85FD for ; Wed, 23 May 2012 22:16:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rb-8QsVkjH8p for ; Wed, 23 May 2012 22:16:30 -0700 (PDT) Received: from ipmail07.adl2.internode.on.net (ipmail07-adl2.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:2:7]) by ietfa.amsl.com (Postfix) with ESMTP id 02C0821F85CF for ; Wed, 23 May 2012 22:16:29 -0700 (PDT) Received: from ppp118-209-124-189.lns20.mel4.internode.on.net (HELO [127.0.0.1]) ([118.209.124.189]) by ipmail07.adl2.internode.on.net with ESMTP; 24 May 2012 14:45:56 +0930 Message-ID: <4FBDC407.5090902@nteczone.com> Date: Thu, 24 May 2012 15:15:51 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: CLUE References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] Updates to CLUE information transport criteria from May 22 DT meeting X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 24 May 2012 05:16:31 -0000 Hello, I'm a little bit puzzled what the aim of the list/exercise is. Christer's original list appeared to be for determining the criteria to select a transport for CLUE. The list below seems now to be on individual data elements? Are we considering only CLUE data elements which I would assume for a CLUE data model? or is the scope broader? A broader scope appears to be suggested by mentioning information for SIP establishment, SDP etc. Some specific comments below: The description of 3) on the expected frequency seems to be mixing how often something will be sent and expected response time based on signalling. Item 5) covers "delay". Should this be merged with 3) or does the description of 3) need to be revised to remove the delay aspect? It would be good to get more information on 8). Are we talking about a heterogeneous use case or a legacy use case? or? Regards, Christian On 24/05/2012 2:48 AM, Mary Barnes wrote: > Per the thread on timing: > http://www.ietf.org/mail-archive/web/clue/current/msg01346.html > I have incorporated what I think were agreed in terms of the 3 > categorizations that Marshall put forth in the item below. We would > need to wordsmith the text to be specific to CLUE but I think the > references to things like IPTV provide a useful > reference/rationalization for the values. > > Ideally, if folks can provide any feedback no later than noon on > Friday, May 25th, the folks doing the data model will have something > to work from. > > Thanks, > Mary. > > On Tue, May 22, 2012 at 11:55 AM, Mary Barnes > wrote: >> Hi all, >> >> This is a summary of updates proposed during today's design team >> meeting, based on Christer's original proposal and Roni's suggested >> additions: >> http://www.ietf.org/mail-archive/web/clue/current/msg01433.html >> >> Note, this a very important thread of discussion as we really need >> someone to step forward to take on detailing the data model and >> evaluate each of the data elements against this criteria: >> >> 1) Whether signaling intermediaries (e.g. SBGs) need to have access to >> the information - i.e.. whether information is relevant to routing >> decisions, policies as to how to route, etc. >> >> -- Whether the CLUE information and the media description (SDP) need >> to be in the same message. >> >> -- Whether the CLUE information and the media description (SDP) need >> to use the same transport path. >> >> 2) The expected size of the information to be sent (i.e., estimate of bytes) >> >> 3) The expected frequency of the information to be sent: > -- 30 msec. This is a video frame. Nothing of significance can > happen faster, and some things, such as video switching, ideally would > only take one frame. > -- 200 msec. This was always viewed as the ideal IPTV channel change > time (and a lot of work was done on IGMP to try and get there). This > also happens to be a rough upper bound on non-noticeable RTTs, and so > is a rough limit on how fast you can do things if those things > require some sort of RT handshake / authorization / acknowledgement. > It would be good to do many CLUE config changes in this > time range - experience is that users will tolerate 200 msec of > interruption or dead time, if something major changes. > -- many seconds. Setting up a conference, changing basic conference > parameters, etc., can take many seconds. Rebooting equipment can take > many seconds. > >> 4) Whether the information is sent during session establishment, mid- >> session and/or session termination. >> >> -- Information for SIP session establishment >> >> -- Information about CLUE, information about media, information to >> establish media >> >> 5) What delay is acceptable for the information (i.e., CLUE data element) >> >> 6) Whether the information is sent as a notification, or whether some >> kind of response is needed >> >> -- Does information need to be carried in a request and response or >> >> -- is it just necessary to be communicated one way >> >> 7) Whether the information needs to be delivered reliably (either >> using a reliable transport mechanism, and/or some kind of >> higher-level acknowledgement) >> >> 8) Whether the information is needed by a non-CLUE entity in order to >> participate in a CLUE conference >> >> -- Not sure the intent here. Christer, can you please clarify what you >> mean by non-CLUE. Also, are you talking about some sort of mapping or >> is this a more theoretical question? >> >> >> >> Thanks, >> Mary. > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From christer.holmberg@ericsson.com Thu May 24 01:49:22 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50FE121F8604 for ; Thu, 24 May 2012 01:49:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3SlLjxdHNt+8 for ; Thu, 24 May 2012 01:49:21 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id DA56721F85FD for ; Thu, 24 May 2012 01:49:20 -0700 (PDT) X-AuditID: c1b4fb2d-b7fac6d000002e89-1b-4fbdf60f655d Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id C8.5B.11913.F06FDBF4; Thu, 24 May 2012 10:49:19 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.250]) by esessmw0184.eemea.ericsson.se ([10.2.3.53]) with mapi; Thu, 24 May 2012 10:49:19 +0200 From: Christer Holmberg To: Christian Groves , CLUE Date: Thu, 24 May 2012 10:48:10 +0200 Thread-Topic: [clue] Updates to CLUE information transport criteria from May 22 DT meeting Thread-Index: Ac05bGRECq3xz8jcRre2iOQn9/UeQAAHY4jB Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C457B1394@ESESSCMS0356.eemea.ericsson.se> References: , <4FBDC407.5090902@nteczone.com> In-Reply-To: <4FBDC407.5090902@nteczone.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrDLMWRmVeSWpSXmKPExsUyM+JvrS7/t73+Br9/GVl8ed/IYrH/1GVm ByaPJUt+MnmsOD+TJYApissmJTUnsyy1SN8ugStj/oR/jAWPNSvm/LrB3sB4QrGLkZNDQsBE 4mvDfDYIW0ziwr31QDYXh5DAKUaJpsPbmCGcuYwSk47eYexi5OBgE7CQ6P6nDdIgIuAlsbd5 JyOIzSKgKvGuaS47iC0sEC3x8e0+NoiaGImrxzcwQ9hGEhNPTGEGGcMrEC5x5IogxPjtjBJT dqxiAanhFNCRuPnzIFgvI9BB30+tYQKxmQXEJW49mc8EcaiAxJI955khbFGJl4//sULUi0rc aV/PCFGvI7Fg9yc2CFtbYtnC12D1vAKCEidnPmGZwCg6C8nYWUhaZiFpmYWkZQEjyypG4dzE zJz0ckO91KLM5OLi/Dy94tRNjMAYObjlt+4OxlPnRA4xSnOwKInzbjbY5S8kkJ5YkpqdmlqQ WhRfVJqTWnyIkYmDU6qBkYuXzc8+clGe8B3fJsE4FiO2gomsjZFOtZG89sKr5Dm/rM3Tq9Q7 9WjxrD9u10/ELfzGJ2DXtm1GZUbZ5nu7Pu5NCrqmyeniuUrxxea095/z+QMYHXMuJB9XMNix 6JaoCqtmvDff2yeLYz2/9HW0hcjcltlR0f99YiPjBI6kj/fM36Wy/j2sxFKckWioxVxUnAgA vVuCy18CAAA= Subject: Re: [clue] Updates to CLUE information transport criteria from May 22 DT meeting X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 24 May 2012 08:49:22 -0000 X-List-Received-Date: Thu, 24 May 2012 08:49:22 -0000 Hi, At least my intention has been to cover all information that is going to be= exchanged. Regards, Christer ________________________________________ From: clue-bounces@ietf.org [clue-bounces@ietf.org] On Behalf Of Christian = Groves [Christian.Groves@nteczone.com] Sent: Thursday, May 24, 2012 8:15 AM To: CLUE Subject: Re: [clue] Updates to CLUE information transport criteria from May= 22 DT meeting Hello, I'm a little bit puzzled what the aim of the list/exercise is. Christer's original list appeared to be for determining the criteria to select a transport for CLUE. The list below seems now to be on individual data elements? Are we considering only CLUE data elements which I would assume for a CLUE data model? or is the scope broader? A broader scope appears to be suggested by mentioning information for SIP establishment, SDP etc. Some specific comments below: The description of 3) on the expected frequency seems to be mixing how often something will be sent and expected response time based on signalling. Item 5) covers "delay". Should this be merged with 3) or does the description of 3) need to be revised to remove the delay aspect? It would be good to get more information on 8). Are we talking about a heterogeneous use case or a legacy use case? or? Regards, Christian On 24/05/2012 2:48 AM, Mary Barnes wrote: > Per the thread on timing: > http://www.ietf.org/mail-archive/web/clue/current/msg01346.html > I have incorporated what I think were agreed in terms of the 3 > categorizations that Marshall put forth in the item below. We would > need to wordsmith the text to be specific to CLUE but I think the > references to things like IPTV provide a useful > reference/rationalization for the values. > > Ideally, if folks can provide any feedback no later than noon on > Friday, May 25th, the folks doing the data model will have something > to work from. > > Thanks, > Mary. > > On Tue, May 22, 2012 at 11:55 AM, Mary Barnes > wrote: >> Hi all, >> >> This is a summary of updates proposed during today's design team >> meeting, based on Christer's original proposal and Roni's suggested >> additions: >> http://www.ietf.org/mail-archive/web/clue/current/msg01433.html >> >> Note, this a very important thread of discussion as we really need >> someone to step forward to take on detailing the data model and >> evaluate each of the data elements against this criteria: >> >> 1) Whether signaling intermediaries (e.g. SBGs) need to have access to >> the information - i.e.. whether information is relevant to routing >> decisions, policies as to how to route, etc. >> >> -- Whether the CLUE information and the media description (SDP) need >> to be in the same message. >> >> -- Whether the CLUE information and the media description (SDP) need >> to use the same transport path. >> >> 2) The expected size of the information to be sent (i.e., estimate of = bytes) >> >> 3) The expected frequency of the information to be sent: > -- 30 msec. This is a video frame. Nothing of significance can > happen faster, and some things, such as video switching, ideally would > only take one frame. > -- 200 msec. This was always viewed as the ideal IPTV channel change > time (and a lot of work was done on IGMP to try and get there). This > also happens to be a rough upper bound on non-noticeable RTTs, and so > is a rough limit on how fast you can do things if those things > require some sort of RT handshake / authorization / acknowledgement. > It would be good to do many CLUE config changes in this > time range - experience is that users will tolerate 200 msec of > interruption or dead time, if something major changes. > -- many seconds. Setting up a conference, changing basic conference > parameters, etc., can take many seconds. Rebooting equipment can take > many seconds. > >> 4) Whether the information is sent during session establishment, mid- >> session and/or session termination. >> >> -- Information for SIP session establishment >> >> -- Information about CLUE, information about media, information to >> establish media >> >> 5) What delay is acceptable for the information (i.e., CLUE data eleme= nt) >> >> 6) Whether the information is sent as a notification, or whether some >> kind of response is needed >> >> -- Does information need to be carried in a request and response or >> >> -- is it just necessary to be communicated one way >> >> 7) Whether the information needs to be delivered reliably (either >> using a reliable transport mechanism, and/or some kind of >> higher-level acknowledgement) >> >> 8) Whether the information is needed by a non-CLUE entity in order to >> participate in a CLUE conference >> >> -- Not sure the intent here. Christer, can you please clarify what you >> mean by non-CLUE. Also, are you talking about some sort of mapping or >> is this a more theoretical question? >> >> >> >> Thanks, >> Mary. > _______________________________________________ > 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= From marshall.eubanks@gmail.com Thu May 24 03:26:20 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A99E821F8623 for ; Thu, 24 May 2012 03:26:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.2 X-Spam-Level: X-Spam-Status: No, score=-103.2 tagged_above=-999 required=5 tests=[AWL=-0.399, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_RAND_LETTRS4=0.799, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tSdBQA1GLjzh for ; Thu, 24 May 2012 03:26:20 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id C64BB21F84C3 for ; Thu, 24 May 2012 03:26:19 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so6718816lbb.31 for ; Thu, 24 May 2012 03:26:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=SFeRMNdHiFf80D6YhiHHFbO4hI4mkHBZSLg0rL9gOdg=; b=dH8VIAyrmyDccHf+1L+vQCioU5tHmuuDJdlwIkTDwUuPFkyL48tHLKhb86Qo2EOWyT oaB34Tprb5AhGC5ZZdDR/Snz+1xAoN4jWnJD1oMch1YJEKXGeFftBVQ/ekB8oPc0nVNH 1JYj839xT8di7IGyHd5a4jRDBt3TmLqwVB9qlkjhKRMi+4WOfLt0VTh912X3sC0JiNHU iJW6nWy56YhUNMD/f/I+bP68ghHMfEgLHUEF7i3ib12DaJdZcxuPT+73zVGdNH4LkE9o zyoAUOF0NQgu05x2RIb5Aovula0+jswhDH55ha0fDwnKolehVkv2kCgaQ+O7ZdWGKypw +ygQ== MIME-Version: 1.0 Received: by 10.112.88.34 with SMTP id bd2mr12302722lbb.33.1337855178636; Thu, 24 May 2012 03:26:18 -0700 (PDT) Received: by 10.112.132.65 with HTTP; Thu, 24 May 2012 03:26:18 -0700 (PDT) In-Reply-To: <02be01cd390c$2d43a0d0$87cae270$@iab.org> References: <02be01cd390c$2d43a0d0$87cae270$@iab.org> Date: Thu, 24 May 2012 06:26:18 -0400 Message-ID: From: Marshall Eubanks To: clue Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [clue] Fwd: Call for Papers: IAB/IRTF Workshop on Congestion Control for Interactive Real-Time Communication, July 28, 2012 Vancouver, Canada X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 24 May 2012 10:26:20 -0000 FYI. CLUE obviously deals with "Interactive Real-Time Communication" Regards Marshall ---------- Forwarded message ---------- From: IAB Chair Date: Wed, May 23, 2012 at 1:47 PM Subject: Call for Papers: IAB/IRTF Workshop on Congestion Control for Interactive Real-Time Communication, July 28, 2012 Vancouver, Canada To: ietf-announce@ietf.org Cc: iab@iab.org IAB / IRTF Workshop on Congestion Control for Interactive Real-Time Communication July 28, 2012 Vancouver, Canada The IAB and IRTF will hold a workshop on Congestion Control for Interactive Real-Time Communication" in Vancouver, Canada on Saturday, July 28th, 2012 prior to the IETF-84 meeting (see http://www.ietf.org/meeting/84/index.html). =A0Participation at the workshop is free of charge. There is no requirement to either register with or attend the IETF-84 meeting that follows the workshop. The workshop organizers would like to foster a discussion on: What are appropriate congestion signals to use for interactive media and da= ta? What existing congestion control algorithms are appropriate for interactive media and data? What properties would be desirable in new congestion control algorithms? Measurement and/or simulations of new congestion signals (e.g., delay-based) and their interaction with existing congestion control mechanisms. What are good available techniques for adjusting sending rates for interactive media and data? What are the limits of those techniques? What properties would be desirable in new techniques? What application-specific considerations have to be taken into account? How can we ensure that real-time communications are well-behaved with respect to other Internet applications while still providing good quality? What should the IETF and/or IRTF do? The organizers seek position papers on any or all of these topics, as well as other topics related to congestion control for interactive realtime media. Every prospective workshop participant must submit a position paper containing a name and an email address. Authors of accepted papers will be invited to the workshop. Papers up to 3 pages, formatted in HTML, PDF, or plain text (for example, as a submitted Internet-Draft) are ideal. Accepted position papers will be published.=A0 Additional details about the meeting venue will be provided to authors of accepted papers. Important Dates Position paper submission deadline: =A0=A0=A0=A0=A0=A0=A0=A0 June 23, 2012 Notification to paper authors: =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0 June 30, 2012 Workshop date: =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 July = 28, 2012 Additional Details Additional details on the workshop as well as the submission process is available at http://www.iab.org/cc-workshop/ Contact To sponsors: If you are interested to help us working towards better interactive media congestion control mechanisms on the Internet (such as by making a contribution towards catering costs and room rental), please contact us! In case of questions please send email to mary.ietf.barnes at gmail.com. From mary.ietf.barnes@gmail.com Thu May 24 08:08:48 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D961E21F8699 for ; Thu, 24 May 2012 08:08:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.609 X-Spam-Level: X-Spam-Status: No, score=-103.609 tagged_above=-999 required=5 tests=[AWL=-0.010, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hKfZzmCAIl8Z for ; Thu, 24 May 2012 08:08:48 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id D7F1C21F8694 for ; Thu, 24 May 2012 08:08:47 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so6684709vbb.31 for ; Thu, 24 May 2012 08:08:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Hp048jyg8zxcxcd9swRnUtdMA4C+q+BMFGT0X0pw02k=; b=SxrTP28Mvk4STfd4Nw6yBvre3k1p/1H8X+XZISTkljPK9oLPAAqGrNELKar10chwcb AUW8AdJnXM69BBYTF28JQ9hYQ2RqnBUqlHb4x6UnU8M3XWSeXAvQOihdvZPJXBLHWtqF z0RO0LlLOfNz3/jTAac+Lahk7Xpqmu3gQkO1rAEybMO+GfhpjHA5NVJPFQHXpP6FZmLB pjnozBof+5SxEqa2DTbDPl6tPOJmjdNsWA4ASRpg5iwT2EkJNmjXlxTX5jcWbeAECzjX r28tXv1ajyZOaiO1YllfHw97stz567zpOtzSDlbZoizv9gmTgBmQDzBg986iFOfkt35i YiyA== MIME-Version: 1.0 Received: by 10.52.97.230 with SMTP id ed6mr15729786vdb.65.1337872127353; Thu, 24 May 2012 08:08:47 -0700 (PDT) Received: by 10.52.22.143 with HTTP; Thu, 24 May 2012 08:08:47 -0700 (PDT) In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C457B1394@ESESSCMS0356.eemea.ericsson.se> References: <4FBDC407.5090902@nteczone.com> <7F2072F1E0DE894DA4B517B93C6A05852C457B1394@ESESSCMS0356.eemea.ericsson.se> Date: Thu, 24 May 2012 10:08:47 -0500 Message-ID: From: Mary Barnes To: Christer Holmberg Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: CLUE Subject: Re: [clue] Updates to CLUE information transport criteria from May 22 DT meeting X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 24 May 2012 15:08:49 -0000 Yes, that was the intent - to characterize the requirements for the information to be exchanged. Then we can then match those with a signaling solution(s) that satisfy the criteria for each of the information elements that need to be exchanged. Mary. On Thu, May 24, 2012 at 3:48 AM, Christer Holmberg wrote: > Hi, > > At least my intention has been to cover all information that is going to = be exchanged. > > Regards, > > Christer > > ________________________________________ > From: clue-bounces@ietf.org [clue-bounces@ietf.org] On Behalf Of Christia= n Groves [Christian.Groves@nteczone.com] > Sent: Thursday, May 24, 2012 8:15 AM > To: CLUE > Subject: Re: [clue] Updates to CLUE information transport criteria from M= ay 22 DT meeting > > Hello, > > I'm a little bit puzzled what the aim of the list/exercise is. > Christer's original list appeared to be for determining the criteria to > select a transport for CLUE. The list below seems now to be on > individual data elements? Are we considering only CLUE data elements > which I would assume for a CLUE data model? or is the scope broader? A > broader scope appears to be suggested by mentioning information for SIP > establishment, SDP etc. > > Some specific comments below: > > The description of 3) on the expected frequency seems to be mixing how > often something will be sent and expected response time based on > signalling. Item 5) covers "delay". Should this be merged with 3) or > does the description of 3) need to be revised to remove the delay aspect? > > It would be good to get more information on 8). Are we talking about a > heterogeneous use case or a legacy use case? or? > > Regards, Christian > > On 24/05/2012 2:48 AM, Mary Barnes wrote: >> Per the thread on timing: >> http://www.ietf.org/mail-archive/web/clue/current/msg01346.html >> I have incorporated what I think were agreed in terms of the 3 >> categorizations that Marshall put forth in the item below. =A0We would >> need to wordsmith the text to be specific to CLUE but I think the >> references to things like IPTV provide a useful >> reference/rationalization for the values. >> >> Ideally, if folks can provide any feedback no later than noon on >> Friday, May 25th, the folks doing the data model will have something >> to work from. >> >> Thanks, >> Mary. >> >> On Tue, May 22, 2012 at 11:55 AM, Mary Barnes >> =A0wrote: >>> Hi all, >>> >>> This is a summary of updates proposed during today's design team >>> meeting, based on Christer's original proposal and Roni's suggested >>> additions: >>> http://www.ietf.org/mail-archive/web/clue/current/msg01433.html >>> >>> Note, this a very important thread of discussion as we really need >>> someone to step forward to take on detailing the data model and >>> evaluate each of the data elements against this criteria: >>> >>> 1) Whether signaling intermediaries (e.g. SBGs) need to have access to >>> =A0 the information - i.e.. whether information is relevant to routing >>> decisions, policies as to how to route, etc. >>> >>> =A0 -- Whether the CLUE information and the media description (SDP) nee= d >>> to be in the same message. >>> >>> -- Whether the CLUE information and the media description (SDP) need >>> to use the same transport path. >>> >>> =A0 2) The expected size of the information to be sent (i.e., estimate = of bytes) >>> >>> =A0 3) The expected frequency of the information to be sent: >> =A0 =A0 -- 30 msec. This is a video frame. Nothing of significance can >> happen faster, and some things, such as video switching, ideally would >> only take one frame. >> =A0 =A0 -- 200 msec. This was always viewed as the ideal IPTV channel ch= ange >> time (and a lot of work was done on IGMP to try and get there). This >> also happens to be a rough upper bound on non-noticeable RTTs, and so >> is a rough =A0limit on how fast you can do things if those things >> require some sort of RT handshake / authorization =A0/ acknowledgement. >> It would be good to do many CLUE config changes in this >> time range - experience is that users will tolerate 200 msec of >> interruption or dead time, if something major changes. >> =A0 =A0-- many seconds. Setting up a conference, changing basic conferen= ce >> parameters, etc., can take many seconds. Rebooting equipment can take >> many seconds. >> >>> =A0 4) Whether the information is sent during session establishment, mi= d- >>> session and/or session termination. >>> >>> -- Information for SIP session establishment >>> >>> -- Information about CLUE, information about media, information to >>> establish media >>> >>> =A0 5) What delay is acceptable for the information (i.e., CLUE data el= ement) >>> >>> 6) Whether the information is sent as a notification, or whether some >>> kind of response is needed >>> >>> -- Does information need to be carried in a request and response or >>> >>> -- is it just necessary to be communicated one way >>> >>> =A0 7) Whether the information needs to be delivered reliably (either >>> using =A0a reliable transport mechanism, and/or some kind of >>> higher-level =A0acknowledgement) >>> >>> 8) Whether the information is needed by a non-CLUE entity in order to >>> participate in a CLUE conference >>> >>> -- Not sure the intent here. Christer, can you please clarify what you >>> mean by non-CLUE. =A0Also, are you talking about some sort of mapping o= r >>> is this a more theoretical question? >>> >>> >>> >>> Thanks, >>> Mary. >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From Even.roni@huawei.com Thu May 24 11:59:13 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4AF821F852A for ; Thu, 24 May 2012 11:59:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y5mum4afw2ij for ; Thu, 24 May 2012 11:59:11 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 16D5821F850B for ; Thu, 24 May 2012 11:59:11 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AGF71993; Thu, 24 May 2012 14:59:10 -0400 (EDT) Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 24 May 2012 11:57:01 -0700 Received: from SZXEML401-HUB.china.huawei.com (10.82.67.31) by dfweml406-hub.china.huawei.com (10.193.5.131) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 24 May 2012 11:57:07 -0700 Received: from SZXEML536-MBX.china.huawei.com ([10.82.67.115]) by szxeml401-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Fri, 25 May 2012 02:57:01 +0800 From: Roni even To: Mary Barnes , Christer Holmberg Thread-Topic: [clue] Updates to CLUE information transport criteria from May 22 DT meeting Thread-Index: AQHNOWxnghVzzhvxOUO+pSwi+0dtyJbYGu8AgABqWICAAMQ6SQ== Date: Thu, 24 May 2012 18:57:01 +0000 Message-ID: References: <4FBDC407.5090902@nteczone.com> <7F2072F1E0DE894DA4B517B93C6A05852C457B1394@ESESSCMS0356.eemea.ericsson.se>, In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.24.1.45] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: CLUE Subject: Re: [clue] Updates to CLUE information transport criteria from May 22 DT meeting X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 24 May 2012 18:59:13 -0000 Hi, This is probably my bad English but I understood the subject as written. I = will look again at the list including the topics I had since it looks to me= that they are not related to the information but more to the transport. I think that the major issue here is that we need to say what messages are = used to carry the information is it two or three messages. This will have a= major impact on the transport since if we need three messages starting wit= h a consumer capabilities this does not work well with offer answer. Roni ________________________________________ From: clue-bounces@ietf.org [clue-bounces@ietf.org] on behalf of Mary Barne= s [mary.ietf.barnes@gmail.com] Sent: Thursday, May 24, 2012 18:08 To: Christer Holmberg Cc: CLUE Subject: Re: [clue] Updates to CLUE information transport criteria from May= 22 DT meeting Yes, that was the intent - to characterize the requirements for the information to be exchanged. Then we can then match those with a signaling solution(s) that satisfy the criteria for each of the information elements that need to be exchanged. Mary. On Thu, May 24, 2012 at 3:48 AM, Christer Holmberg wrote: > Hi, > > At least my intention has been to cover all information that is going to = be exchanged. > > Regards, > > Christer > > ________________________________________ > From: clue-bounces@ietf.org [clue-bounces@ietf.org] On Behalf Of Christia= n Groves [Christian.Groves@nteczone.com] > Sent: Thursday, May 24, 2012 8:15 AM > To: CLUE > Subject: Re: [clue] Updates to CLUE information transport criteria from M= ay 22 DT meeting > > Hello, > > I'm a little bit puzzled what the aim of the list/exercise is. > Christer's original list appeared to be for determining the criteria to > select a transport for CLUE. The list below seems now to be on > individual data elements? Are we considering only CLUE data elements > which I would assume for a CLUE data model? or is the scope broader? A > broader scope appears to be suggested by mentioning information for SIP > establishment, SDP etc. > > Some specific comments below: > > The description of 3) on the expected frequency seems to be mixing how > often something will be sent and expected response time based on > signalling. Item 5) covers "delay". Should this be merged with 3) or > does the description of 3) need to be revised to remove the delay aspect? > > It would be good to get more information on 8). Are we talking about a > heterogeneous use case or a legacy use case? or? > > Regards, Christian > > On 24/05/2012 2:48 AM, Mary Barnes wrote: >> Per the thread on timing: >> http://www.ietf.org/mail-archive/web/clue/current/msg01346.html >> I have incorporated what I think were agreed in terms of the 3 >> categorizations that Marshall put forth in the item below. We would >> need to wordsmith the text to be specific to CLUE but I think the >> references to things like IPTV provide a useful >> reference/rationalization for the values. >> >> Ideally, if folks can provide any feedback no later than noon on >> Friday, May 25th, the folks doing the data model will have something >> to work from. >> >> Thanks, >> Mary. >> >> On Tue, May 22, 2012 at 11:55 AM, Mary Barnes >> wrote: >>> Hi all, >>> >>> This is a summary of updates proposed during today's design team >>> meeting, based on Christer's original proposal and Roni's suggested >>> additions: >>> http://www.ietf.org/mail-archive/web/clue/current/msg01433.html >>> >>> Note, this a very important thread of discussion as we really need >>> someone to step forward to take on detailing the data model and >>> evaluate each of the data elements against this criteria: >>> >>> 1) Whether signaling intermediaries (e.g. SBGs) need to have access to >>> the information - i.e.. whether information is relevant to routing >>> decisions, policies as to how to route, etc. >>> >>> -- Whether the CLUE information and the media description (SDP) need >>> to be in the same message. >>> >>> -- Whether the CLUE information and the media description (SDP) need >>> to use the same transport path. >>> >>> 2) The expected size of the information to be sent (i.e., estimate of= bytes) >>> >>> 3) The expected frequency of the information to be sent: >> -- 30 msec. This is a video frame. Nothing of significance can >> happen faster, and some things, such as video switching, ideally would >> only take one frame. >> -- 200 msec. This was always viewed as the ideal IPTV channel change >> time (and a lot of work was done on IGMP to try and get there). This >> also happens to be a rough upper bound on non-noticeable RTTs, and so >> is a rough limit on how fast you can do things if those things >> require some sort of RT handshake / authorization / acknowledgement. >> It would be good to do many CLUE config changes in this >> time range - experience is that users will tolerate 200 msec of >> interruption or dead time, if something major changes. >> -- many seconds. Setting up a conference, changing basic conference >> parameters, etc., can take many seconds. Rebooting equipment can take >> many seconds. >> >>> 4) Whether the information is sent during session establishment, mid- >>> session and/or session termination. >>> >>> -- Information for SIP session establishment >>> >>> -- Information about CLUE, information about media, information to >>> establish media >>> >>> 5) What delay is acceptable for the information (i.e., CLUE data elem= ent) >>> >>> 6) Whether the information is sent as a notification, or whether some >>> kind of response is needed >>> >>> -- Does information need to be carried in a request and response or >>> >>> -- is it just necessary to be communicated one way >>> >>> 7) Whether the information needs to be delivered reliably (either >>> using a reliable transport mechanism, and/or some kind of >>> higher-level acknowledgement) >>> >>> 8) Whether the information is needed by a non-CLUE entity in order to >>> participate in a CLUE conference >>> >>> -- Not sure the intent here. Christer, can you please clarify what you >>> mean by non-CLUE. Also, are you talking about some sort of mapping or >>> is this a more theoretical question? >>> >>> >>> >>> Thanks, >>> Mary. >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue= From mary.ietf.barnes@gmail.com Thu May 24 12:11:14 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E580F11E80C5 for ; Thu, 24 May 2012 12:11:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.608 X-Spam-Level: X-Spam-Status: No, score=-103.608 tagged_above=-999 required=5 tests=[AWL=-0.009, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vk2Ld+ut3w+c for ; Thu, 24 May 2012 12:11:13 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id AA05711E80C1 for ; Thu, 24 May 2012 12:11:12 -0700 (PDT) Received: by vcqp1 with SMTP id p1so76007vcq.31 for ; Thu, 24 May 2012 12:11:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=b1OGg3hhZvihLe7QhxJiUja/ZkaEUU9Xi/wHMPUfr6I=; b=qNlabwd/Bw5BzQn2XU7mec55jnxS2dMM8CnVtzmD4Aw/Hwzd/WM4a8tuMotNXfeoAv oZFNQjidWLXRcIWSQK058LXVTEy36f2wYsfu3z9vmXzMhe8bUdFluekOv+hLAECT7QW1 r6AQS6CeLOnxTohqwyY0xhYcfCQT0e0y1ZQjVk/KzmDBoaqgQmU/0bbikJ5Nr4L1Ky8J x/BjkADlPW4MB3HcOEHNo4O5y7oHTb0SLj8nhWvzgdKbmnat6MQlJbv3FKtfJ7W14nzQ FYGkpk8xycPjFDj2f9M+0i1iKhKY+Bjo63e2rV1AkD+QKMswzsUK6pbxqj7gYAnJBLeb QQwQ== MIME-Version: 1.0 Received: by 10.52.73.73 with SMTP id j9mr503501vdv.53.1337886672190; Thu, 24 May 2012 12:11:12 -0700 (PDT) Received: by 10.52.22.143 with HTTP; Thu, 24 May 2012 12:11:12 -0700 (PDT) In-Reply-To: References: <4FBDC407.5090902@nteczone.com> <7F2072F1E0DE894DA4B517B93C6A05852C457B1394@ESESSCMS0356.eemea.ericsson.se> Date: Thu, 24 May 2012 14:11:12 -0500 Message-ID: From: Mary Barnes To: Roni even Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: CLUE Subject: Re: [clue] Updates to CLUE information transport criteria from May 22 DT meeting X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 24 May 2012 19:11:14 -0000 It's a chicken/egg thing. But, I think whether there are two or three messages is slightly orthogonal. I can see that once we actually have a data model and identify the criteria required to transport the information to achieve the desired functionality that it will be easier to decide what transport mechanism is appropriate. Some of this was already considered in this draft: http://www.ietf.org/id/draft-romanow-clue-sdp-usage-01.txt Mary. On Thu, May 24, 2012 at 1:57 PM, Roni even wrote: > Hi, > This is probably my bad English but I understood the subject as written. = I will look again at the list including the topics I had since it looks to = me that they are not related to the information but more to the transport. > > I think that the major issue here is that we need to say what messages ar= e used to carry the information is it two or three messages. This will have= a major impact on the transport since if we need three messages starting w= ith a consumer capabilities this does not work well with offer answer. > > Roni > > ________________________________________ > From: clue-bounces@ietf.org [clue-bounces@ietf.org] on behalf of Mary Bar= nes [mary.ietf.barnes@gmail.com] > Sent: Thursday, May 24, 2012 18:08 > To: Christer Holmberg > Cc: CLUE > Subject: Re: [clue] Updates to CLUE information transport criteria from M= ay 22 DT meeting > > Yes, that was the intent - to characterize the requirements for the > information to be exchanged. Then we can then match those with a > signaling solution(s) that satisfy the criteria for each of the > information elements that need to be exchanged. > > Mary. > > On Thu, May 24, 2012 at 3:48 AM, Christer Holmberg > wrote: >> Hi, >> >> At least my intention has been to cover all information that is going to= be exchanged. >> >> Regards, >> >> Christer >> >> ________________________________________ >> From: clue-bounces@ietf.org [clue-bounces@ietf.org] On Behalf Of Christi= an Groves [Christian.Groves@nteczone.com] >> Sent: Thursday, May 24, 2012 8:15 AM >> To: CLUE >> Subject: Re: [clue] Updates to CLUE information transport criteria from = May 22 DT meeting >> >> Hello, >> >> I'm a little bit puzzled what the aim of the list/exercise is. >> Christer's original list appeared to be for determining the criteria to >> select a transport for CLUE. The list below seems now to be on >> individual data elements? Are we considering only CLUE data elements >> which I would assume for a CLUE data model? or is the scope broader? A >> broader scope appears to be suggested by mentioning information for SIP >> establishment, SDP etc. >> >> Some specific comments below: >> >> The description of 3) on the expected frequency seems to be mixing how >> often something will be sent and expected response time based on >> signalling. Item 5) covers "delay". Should this be merged with 3) or >> does the description of 3) need to be revised to remove the delay aspect= ? >> >> It would be good to get more information on 8). Are we talking about a >> heterogeneous use case or a legacy use case? or? >> >> Regards, Christian >> >> On 24/05/2012 2:48 AM, Mary Barnes wrote: >>> Per the thread on timing: >>> http://www.ietf.org/mail-archive/web/clue/current/msg01346.html >>> I have incorporated what I think were agreed in terms of the 3 >>> categorizations that Marshall put forth in the item below. =A0We would >>> need to wordsmith the text to be specific to CLUE but I think the >>> references to things like IPTV provide a useful >>> reference/rationalization for the values. >>> >>> Ideally, if folks can provide any feedback no later than noon on >>> Friday, May 25th, the folks doing the data model will have something >>> to work from. >>> >>> Thanks, >>> Mary. >>> >>> On Tue, May 22, 2012 at 11:55 AM, Mary Barnes >>> =A0wrote: >>>> Hi all, >>>> >>>> This is a summary of updates proposed during today's design team >>>> meeting, based on Christer's original proposal and Roni's suggested >>>> additions: >>>> http://www.ietf.org/mail-archive/web/clue/current/msg01433.html >>>> >>>> Note, this a very important thread of discussion as we really need >>>> someone to step forward to take on detailing the data model and >>>> evaluate each of the data elements against this criteria: >>>> >>>> 1) Whether signaling intermediaries (e.g. SBGs) need to have access to >>>> =A0 the information - i.e.. whether information is relevant to routing >>>> decisions, policies as to how to route, etc. >>>> >>>> =A0 -- Whether the CLUE information and the media description (SDP) ne= ed >>>> to be in the same message. >>>> >>>> -- Whether the CLUE information and the media description (SDP) need >>>> to use the same transport path. >>>> >>>> =A0 2) The expected size of the information to be sent (i.e., estimate= of bytes) >>>> >>>> =A0 3) The expected frequency of the information to be sent: >>> =A0 =A0 -- 30 msec. This is a video frame. Nothing of significance can >>> happen faster, and some things, such as video switching, ideally would >>> only take one frame. >>> =A0 =A0 -- 200 msec. This was always viewed as the ideal IPTV channel c= hange >>> time (and a lot of work was done on IGMP to try and get there). This >>> also happens to be a rough upper bound on non-noticeable RTTs, and so >>> is a rough =A0limit on how fast you can do things if those things >>> require some sort of RT handshake / authorization =A0/ acknowledgement. >>> It would be good to do many CLUE config changes in this >>> time range - experience is that users will tolerate 200 msec of >>> interruption or dead time, if something major changes. >>> =A0 =A0-- many seconds. Setting up a conference, changing basic confere= nce >>> parameters, etc., can take many seconds. Rebooting equipment can take >>> many seconds. >>> >>>> =A0 4) Whether the information is sent during session establishment, m= id- >>>> session and/or session termination. >>>> >>>> -- Information for SIP session establishment >>>> >>>> -- Information about CLUE, information about media, information to >>>> establish media >>>> >>>> =A0 5) What delay is acceptable for the information (i.e., CLUE data e= lement) >>>> >>>> 6) Whether the information is sent as a notification, or whether some >>>> kind of response is needed >>>> >>>> -- Does information need to be carried in a request and response or >>>> >>>> -- is it just necessary to be communicated one way >>>> >>>> =A0 7) Whether the information needs to be delivered reliably (either >>>> using =A0a reliable transport mechanism, and/or some kind of >>>> higher-level =A0acknowledgement) >>>> >>>> 8) Whether the information is needed by a non-CLUE entity in order to >>>> participate in a CLUE conference >>>> >>>> -- Not sure the intent here. Christer, can you please clarify what you >>>> mean by non-CLUE. =A0Also, are you talking about some sort of mapping = or >>>> is this a more theoretical question? >>>> >>>> >>>> >>>> Thanks, >>>> Mary. >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >>> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From Even.roni@huawei.com Thu May 24 14:10:53 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CC8221F8568 for ; Thu, 24 May 2012 14:10:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3qA221rFRLz7 for ; Thu, 24 May 2012 14:10:52 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id C42A521F8562 for ; Thu, 24 May 2012 14:10:51 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AGM80440; Thu, 24 May 2012 17:10:49 -0400 (EDT) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 24 May 2012 14:09:49 -0700 Received: from SZXEML419-HUB.china.huawei.com (10.82.67.158) by dfweml404-hub.china.huawei.com (10.193.5.203) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 24 May 2012 14:09:47 -0700 Received: from SZXEML536-MBX.china.huawei.com ([10.82.67.115]) by szxeml419-hub.china.huawei.com ([10.82.67.158]) with mapi id 14.01.0323.003; Fri, 25 May 2012 05:09:42 +0800 From: Roni even To: Mary Barnes Thread-Topic: [clue] Updates to CLUE information transport criteria from May 22 DT meeting Thread-Index: AQHNOWxnghVzzhvxOUO+pSwi+0dtyJbYGu8AgABqWICAAMQ6Sf//f4EAgACmO7s= Date: Thu, 24 May 2012 21:09:41 +0000 Message-ID: References: <4FBDC407.5090902@nteczone.com> <7F2072F1E0DE894DA4B517B93C6A05852C457B1394@ESESSCMS0356.eemea.ericsson.se> , In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.24.1.45] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: CLUE Subject: Re: [clue] Updates to CLUE information transport criteria from May 22 DT meeting X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 24 May 2012 21:10:53 -0000 Mary, I am sorry but this is not a chicken and egg thing.=20 This is a basic CLUE framework issue. If the view is that the provider will= send advertisements based on the consumer capabilities or whether he will = send advertisements based on his capabilities is a fundamental question tha= t will have a major influence on the transport type. Roni ________________________________________ From: Mary Barnes [mary.ietf.barnes@gmail.com] Sent: Thursday, May 24, 2012 22:11 To: Roni even Cc: Christer Holmberg; CLUE Subject: Re: [clue] Updates to CLUE information transport criteria from May= 22 DT meeting It's a chicken/egg thing. But, I think whether there are two or three messages is slightly orthogonal. I can see that once we actually have a data model and identify the criteria required to transport the information to achieve the desired functionality that it will be easier to decide what transport mechanism is appropriate. Some of this was already considered in this draft: http://www.ietf.org/id/draft-romanow-clue-sdp-usage-01.txt Mary. On Thu, May 24, 2012 at 1:57 PM, Roni even wrote: > Hi, > This is probably my bad English but I understood the subject as written. = I will look again at the list including the topics I had since it looks to = me that they are not related to the information but more to the transport. > > I think that the major issue here is that we need to say what messages ar= e used to carry the information is it two or three messages. This will have= a major impact on the transport since if we need three messages starting w= ith a consumer capabilities this does not work well with offer answer. > > Roni > > ________________________________________ > From: clue-bounces@ietf.org [clue-bounces@ietf.org] on behalf of Mary Bar= nes [mary.ietf.barnes@gmail.com] > Sent: Thursday, May 24, 2012 18:08 > To: Christer Holmberg > Cc: CLUE > Subject: Re: [clue] Updates to CLUE information transport criteria from M= ay 22 DT meeting > > Yes, that was the intent - to characterize the requirements for the > information to be exchanged. Then we can then match those with a > signaling solution(s) that satisfy the criteria for each of the > information elements that need to be exchanged. > > Mary. > > On Thu, May 24, 2012 at 3:48 AM, Christer Holmberg > wrote: >> Hi, >> >> At least my intention has been to cover all information that is going to= be exchanged. >> >> Regards, >> >> Christer >> >> ________________________________________ >> From: clue-bounces@ietf.org [clue-bounces@ietf.org] On Behalf Of Christi= an Groves [Christian.Groves@nteczone.com] >> Sent: Thursday, May 24, 2012 8:15 AM >> To: CLUE >> Subject: Re: [clue] Updates to CLUE information transport criteria from = May 22 DT meeting >> >> Hello, >> >> I'm a little bit puzzled what the aim of the list/exercise is. >> Christer's original list appeared to be for determining the criteria to >> select a transport for CLUE. The list below seems now to be on >> individual data elements? Are we considering only CLUE data elements >> which I would assume for a CLUE data model? or is the scope broader? A >> broader scope appears to be suggested by mentioning information for SIP >> establishment, SDP etc. >> >> Some specific comments below: >> >> The description of 3) on the expected frequency seems to be mixing how >> often something will be sent and expected response time based on >> signalling. Item 5) covers "delay". Should this be merged with 3) or >> does the description of 3) need to be revised to remove the delay aspect= ? >> >> It would be good to get more information on 8). Are we talking about a >> heterogeneous use case or a legacy use case? or? >> >> Regards, Christian >> >> On 24/05/2012 2:48 AM, Mary Barnes wrote: >>> Per the thread on timing: >>> http://www.ietf.org/mail-archive/web/clue/current/msg01346.html >>> I have incorporated what I think were agreed in terms of the 3 >>> categorizations that Marshall put forth in the item below. We would >>> need to wordsmith the text to be specific to CLUE but I think the >>> references to things like IPTV provide a useful >>> reference/rationalization for the values. >>> >>> Ideally, if folks can provide any feedback no later than noon on >>> Friday, May 25th, the folks doing the data model will have something >>> to work from. >>> >>> Thanks, >>> Mary. >>> >>> On Tue, May 22, 2012 at 11:55 AM, Mary Barnes >>> wrote: >>>> Hi all, >>>> >>>> This is a summary of updates proposed during today's design team >>>> meeting, based on Christer's original proposal and Roni's suggested >>>> additions: >>>> http://www.ietf.org/mail-archive/web/clue/current/msg01433.html >>>> >>>> Note, this a very important thread of discussion as we really need >>>> someone to step forward to take on detailing the data model and >>>> evaluate each of the data elements against this criteria: >>>> >>>> 1) Whether signaling intermediaries (e.g. SBGs) need to have access to >>>> the information - i.e.. whether information is relevant to routing >>>> decisions, policies as to how to route, etc. >>>> >>>> -- Whether the CLUE information and the media description (SDP) need >>>> to be in the same message. >>>> >>>> -- Whether the CLUE information and the media description (SDP) need >>>> to use the same transport path. >>>> >>>> 2) The expected size of the information to be sent (i.e., estimate o= f bytes) >>>> >>>> 3) The expected frequency of the information to be sent: >>> -- 30 msec. This is a video frame. Nothing of significance can >>> happen faster, and some things, such as video switching, ideally would >>> only take one frame. >>> -- 200 msec. This was always viewed as the ideal IPTV channel chang= e >>> time (and a lot of work was done on IGMP to try and get there). This >>> also happens to be a rough upper bound on non-noticeable RTTs, and so >>> is a rough limit on how fast you can do things if those things >>> require some sort of RT handshake / authorization / acknowledgement. >>> It would be good to do many CLUE config changes in this >>> time range - experience is that users will tolerate 200 msec of >>> interruption or dead time, if something major changes. >>> -- many seconds. Setting up a conference, changing basic conference >>> parameters, etc., can take many seconds. Rebooting equipment can take >>> many seconds. >>> >>>> 4) Whether the information is sent during session establishment, mid= - >>>> session and/or session termination. >>>> >>>> -- Information for SIP session establishment >>>> >>>> -- Information about CLUE, information about media, information to >>>> establish media >>>> >>>> 5) What delay is acceptable for the information (i.e., CLUE data ele= ment) >>>> >>>> 6) Whether the information is sent as a notification, or whether some >>>> kind of response is needed >>>> >>>> -- Does information need to be carried in a request and response or >>>> >>>> -- is it just necessary to be communicated one way >>>> >>>> 7) Whether the information needs to be delivered reliably (either >>>> using a reliable transport mechanism, and/or some kind of >>>> higher-level acknowledgement) >>>> >>>> 8) Whether the information is needed by a non-CLUE entity in order to >>>> participate in a CLUE conference >>>> >>>> -- Not sure the intent here. Christer, can you please clarify what you >>>> mean by non-CLUE. Also, are you talking about some sort of mapping or >>>> is this a more theoretical question? >>>> >>>> >>>> >>>> Thanks, >>>> Mary. >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >>> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue= From mary.ietf.barnes@gmail.com Thu May 24 14:57:44 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3003011E80A3 for ; Thu, 24 May 2012 14:57:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.608 X-Spam-Level: X-Spam-Status: No, score=-103.608 tagged_above=-999 required=5 tests=[AWL=-0.009, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2CDXCDw64yAc for ; Thu, 24 May 2012 14:57:42 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 006EB11E8081 for ; Thu, 24 May 2012 14:57:41 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so252658vbb.31 for ; Thu, 24 May 2012 14:57:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=LfV4JlAt0+h1UPlLJ4yK2vdhUNMcgjvKqAfcvryZBA4=; b=Y1jXESw7C7Vp0g6EJ99o7oMvanAfQJezEXyZ/3uKvrIn+tJJ4LiY6eTA+l0qfRURDN 1qbRG804C85iwaYAodn4LGAmNoRgAFAxQqo36hIHkDJfQZH/rIjCFR4X286Ixucu7fWy IWQOw9mvUd/NL8Vua/vgVXvyPvWQcp+904rAsKfRWLMsf4C1FLq/CzJiRGhiVrF0ybRq BIzGM47IlzWxLaEmK2hy4LvYU+AGKKayMk82LPrp2VGsl4iY9QJHw4Miif53Y6ciy8Q2 tN4/Fsg2g5XThuGnUosExoCehXx6CdCyMLaxeRTZbb/lTyJR3t4xzL4TyHRKOHUzCp3E OAMQ== MIME-Version: 1.0 Received: by 10.52.28.71 with SMTP id z7mr885445vdg.105.1337896661530; Thu, 24 May 2012 14:57:41 -0700 (PDT) Received: by 10.52.22.143 with HTTP; Thu, 24 May 2012 14:57:41 -0700 (PDT) In-Reply-To: References: Date: Thu, 24 May 2012 16:57:41 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [clue] *Updated Consensus Call*: Add description text to a capture scene? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 24 May 2012 21:57:44 -0000 At this point (2 hours shy of the deadline to express your opinion), there are a total of 8 responses answering the questions: 1) Yes (1), No (7) 2) Yes (8), No (0) 3) Yes (0), No (8) Again, please respond by 5pm Pacific today, so that the decision can be reflected in the next version of the framework document. If the text string is agreed to be added (as it seems likely), it will have to support multiple languages as Roni highlighted. Thanks, Mary. On Tue, May 22, 2012 at 12:10 PM, Mary Barnes wrote: > Per Marshall's feedback, I am reposing the questions to consider the > optional aspect (which is what I think we have been discussing, but > just to be clear). > > 1) Do you agree that we should add a mandatory element with human > readable text to the capture scene? > 2) Do you agree that we should add an optional element with human > readable text to the capture scene? > 3) Do you agree that we should not add any optional or mandatory human > readable text to the capture scene? > > Thanks, > Mary. > > On Tue, May 22, 2012 at 11:36 AM, Mary Barnes > wrote: >> Resending with a new Subject just to make sure folks pick up on this as = a >> Consensus call. >> >> On Tue, May 22, 2012 at 11:35 AM, Mary Barnes >> wrote: >>> >>> Hi all, >>> >>> Per the design team meeting this morning, we are doing a consensus call= on >>> the question as to whether human readable text string should be added t= o the >>> capture scene. >>> >>> Note that while this came up during discussion of Ticket #8 in a previo= us >>> meeting, it does not impact the state of Ticket #8 which remains open: >>> http://trac.tools.ietf.org/wg/clue/trac/ticket/8 (How consumer >>> differentiates between multiple capture scenes) >>> >>> So, if folks could please respond to the following question with a "Yes= " >>> or "No": >>> >>> Should a human readable text string be added to the capture scene in th= e >>> framework document? >>> >>> It would also be helpful (but not required for consensus) if folks coul= d >>> provide a brief statement justifying their response for the WG members = that >>> did not hear the discussion on today's call. >>> >>> The consensus call closes on Thursday at 5pm Pacific. >>> >>> Thanks, >>> Mary >>> CLUE WG co-chair >>> >>> >>> >>> >>> On Fri, May 18, 2012 at 11:56 AM, Duckworth, Mark >>> wrote: >>>> >>>> Regarding Ticket #8 - How consumer differentiates between multiple >>>> capture scenes. >>>> We discussed this a bit on the list, and on the April 10 phone meeting= . >>>> =A0I think the group agreed we should add a human readable text string >>>> attribute to a capture scene. >>>> >>>> Here is a proposal for adding text to the framework document section >>>> 6.2.1 Capture scene attributes: >>>> >>>> Description attribute >>>> >>>> The description attribute is a human readable text string which descri= bes >>>> the capture scene. =A0A provider that advertises multiple capture scen= es may >>>> use different descriptions to differentiate between them. >>>> >>>> >>>> Do we also want to add a similar description attribute to a media >>>> capture? >>>> >>>> Mark Duckworth >>>> _______________________________________________ >>>> clue mailing list >>>> clue@ietf.org >>>> https://www.ietf.org/mailman/listinfo/clue >>> >>> >> From Mark.Duckworth@polycom.com Thu May 24 15:16:08 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 607C211E8080 for ; Thu, 24 May 2012 15:16:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ywi+uFZ0wBJm for ; Thu, 24 May 2012 15:16:05 -0700 (PDT) Received: from Crpehubprd01.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 0379811E808A for ; Thu, 24 May 2012 15:16:02 -0700 (PDT) Received: from Crpmboxprd01.polycom.com ([fe80::ad68:5a0:c919:66b6]) by Crpehubprd01.polycom.com ([fe80::5efe:10.236.0.158%14]) with mapi; Thu, 24 May 2012 15:16:02 -0700 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Thu, 24 May 2012 15:15:59 -0700 Thread-Topic: capture attributes - content attribute Thread-Index: Ac04RnZOA9sBnQ6tSvaEcDiurur32QBsfufg Message-ID: <44C6B6B2D0CF424AA90B6055548D7A6102FD96A17C@CRPMBOXPRD01.polycom.com> References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC0782890E@xmb-sjc-221.amer.cisco.com> In-Reply-To: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC0782890E@xmb-sjc-221.amer.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_44C6B6B2D0CF424AA90B6055548D7A6102FD96A17CCRPMBOXPRD01p_" MIME-Version: 1.0 Subject: Re: [clue] capture attributes - content attribute X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 24 May 2012 22:16:08 -0000 --_000_44C6B6B2D0CF424AA90B6055548D7A6102FD96A17CCRPMBOXPRD01p_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I think it would be good for CLUE to have easy interoperability with existi= ng devices that follow the IMTC document for Role Based Video Streams. So = it makes sense to me for CLUE to have one attribute with only two specific = values, that map directly to the content attribute values of main and slide= s that are used for RBVS. I don't care too much what we name we give to it= , as long as somehow it is specified how to map it to the RBVS usage. For extensibility, if we add more possible values than just main and slides= , would we want to relate it to RBVS somehow? For example if there is a "s= peaker" but no "main", would the speaker be treated as "main"? Or if there= is a "speaker" and "main", then the legacy RBVS system should see the "mai= n" one but not "speaker"? Or would it be better for extensibility to have a separate attribute name w= hich can take on more new values? For example: Attribute: content - possible values: {main, slides} Attribute: clue-extensible-role - possible values: {speaker, sign language= , audience, ...} A media capture could use both attributes, for example content=3Dmain, clue= -extensible-role=3Daudience. Would that work? Do you see a significant di= fference between extending it this way, rather than adding more possible va= lues to the content attribute? Adding more roles seems related to Ticket #8 also. People (including me) h= ave suggested using such additional role attributes to distinguish between = multiple capture scenes. Mark From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of All= yn Romanow (allyn) Sent: Tuesday, May 22, 2012 2:13 PM To: CLUE Subject: [clue] capture attributes - content attribute Folks, Earlier we changed the capture attribute "purpose" with values presentatio= n and main to content attribute taken from RFC 4976 with content types slid= es, main, speaker, Initially, when this came up, I thought it was a simple change and it had = the appeal of using an existing RFC, so I wasn't opposed to it. However, in= working on a proof of concept implementation, this seemed to have issues a= nd I feel we should stay with purpose and main and presentation, or at the= most, change it to content with main and slides as did the IMTC SIP Parity= WG for Role Based Video Streams. My primary reason for wanting to define only main and presentation (or cont= ent attributes main and slides from the full list in RFC 4796) is similar t= o the reasoning from the SIP Parity WG - that in a conference It can easily= create confusion and lack of non-interoperability - for example one syste= m may use main and another speaker when referring to the same situation. = This same view was actually expressed in the Role Based Video Stream work = in IMTC SIP Parity WG which decided to support only main and slides. Here is what is in the RBVS document on this topic (of course they aren't u= sing the attributes for audio, just video). Unlike H.239 where there are only two channel roles, "live" and "presentati= on", in SIP, there are more roles, and it is possible that endpoints and MC= Us will have to deal with the situation where all of the participants in a = call do not designate the same roles for their channels. For example, one = endpoint in a multipoint conference may use the "speaker" and "slides" role= s for its video channels, while another may use "main" and "alt" for its vi= deo channels. Since there are no mechanisms to enable MCUs and endpoints = to interoperate in this type of situation, all SIP-based endpoints conformi= ng to the RBVS "Best Practices" Profile MUST use the attributes as specifie= d in this section. [ i.e., main and slides] The handling of other 'content'= attribute values is considered out of scope. Although I'm okay with using just slides and main from the content attribut= e, I feel that purpose: presentation, main map better to audio than do slid= es and main. I noticed today during the CLUE WG meeting that people reverted to speaking= about purpose main and presentation instead of the new content attribute c= ategories.. which is just an anecdote suggesting that we stick with what we= first had. Of course, I'm assuming that we add any values to purpose (or content) as t= hey arise. Thoughts? --_000_44C6B6B2D0CF424AA90B6055548D7A6102FD96A17CCRPMBOXPRD01p_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I think it would be good for CLUE to have easy interoperabili= ty with existing devices that follow the IMTC document for Role Based Video= Streams.  So it makes sense to me for CLUE to have one attribute with= only two specific values, that map directly to the content attribute value= s of main and slides that are used for RBVS.  I don’t care too m= uch what we name we give to it, as long as somehow it is specified how to m= ap it to the RBVS usage.

 

For extensibility, if we add more possible values= than just main and slides, would we want to relate it to RBVS somehow?&nbs= p; For example if there is a “speaker” but no “main”= ;, would the speaker be treated as “main”?  Or if there is= a “speaker” and “main”, then the legacy RBVS syste= m should see the “main” one but not “speaker”?=

&n= bsp;

Or = would it be better for extensibility to have a separate attribute name whic= h can take on more new values?  For example:

  Attribute: content &#= 8211; possible values: {main, slides}

 Attribute: clue-extensible-role &= #8211; possible values: {speaker, sign language, audience, …}

 = ;

A medi= a capture could use both attributes, for example content=3Dmain, clue-exten= sible-role=3Daudience.  Would that work?  Do you see a significan= t difference between extending it this way, rather than adding more possibl= e values to the content attribute?

 

Adding more roles seems related to Tick= et #8 also.  People (including me) have suggested using such additiona= l role attributes to distinguish between multiple capture scenes.

 <= /o:p>

Mark

&= nbsp;

 

From:= clu= e-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Allyn= Romanow (allyn)
Sent: Tuesday, May 22, 2012 2:13 PM
To: CLUE
Subject: [clue] capture attributes - content attribute

 

Folks,

Earlier we cha= nged  the capture attribute “purpose” with values presenta= tion and main to content attribute taken from RFC 4976 with content types s= lides, main, speaker,

 =

Initially, when this came up,  I thought it w= as a simple change and it had the appeal of using an existing RFC, so I was= n’t opposed to it. However, in working on a proof of concept implemen= tation, this seemed to have issues and  I feel we should stay with pur= pose and main and presentation, or at the most, change it to content with m= ain and slides as did the IMTC SIP Parity WG for Role Based Video Streams.<= o:p>

 

My primary reason for wanting to define only main and presentation (or co= ntent attributes main and slides from the full list in RFC 4796) is similar= to the reasoning from the SIP Parity WG – that in a conference It ca= n easily create  confusion and lack of non-interoperability – fo= r example one system may use main and another speaker when referring to the= same situation.    This same view was actually expressed in= the Role Based Video Stream work in IMTC SIP Parity WG which decided  = ;to support only main and slides.  

 

Here is what is in the RBVS docu= ment on this topic (of course they aren’t using the attributes for au= dio, just video).

 

<= p class=3DMsoNormal style=3D'margin-left:.5in;text-align:justify;text-inden= t:2.6pt'>Unlike H.239 where there are only two channel roles, “live&#= 8221; and “presentation”, in SIP, there are more roles, and it = is possible that endpoints and MCUs will have to deal with the situation wh= ere all of the participants in a call do not designate the same roles for t= heir channels.  For example, one endpoint in a multipoint conference m= ay use the “speaker” and “slides” roles for its vid= eo channels, while another may use “main” and “alt”= for its video channels.   Since there are no mechanisms to enabl= e MCUs and endpoints to interoperate in this type of situation, all SIP-bas= ed endpoints conforming to the RBVS “Best Practices” Profile MU= ST use the attributes as specified in this section. [ i.e., main and slides= ] The handling of other ‘content’ attribute values is considere= d out of scope.

 

=

 

Although I&#= 8217;m okay with using just slides and main from the content attribute, I f= eel that purpose: presentation, main map better to audio than do slides and= main.

 

I noticed today during the CLUE WG meeting that people reverted to= speaking about purpose main and presentation instead of the new content at= tribute categories.. which is just an anecdote suggesting that we stick wit= h what we first had.

 

Of course, I’m assuming that we add any values= to purpose (or content) as they arise.

=  

Thoughts?

= --_000_44C6B6B2D0CF424AA90B6055548D7A6102FD96A17CCRPMBOXPRD01p_-- From pkyzivat@alum.mit.edu Thu May 24 16:05:42 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27CF911E80B3 for ; Thu, 24 May 2012 16:05:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XnWP8d3tLQpm for ; Thu, 24 May 2012 16:05:28 -0700 (PDT) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [76.96.62.16]) by ietfa.amsl.com (Postfix) with ESMTP id 1D2A421F8518 for ; Thu, 24 May 2012 16:05:27 -0700 (PDT) Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta01.westchester.pa.mail.comcast.net with comcast id Dvil1j0061vXlb851z5TYM; Thu, 24 May 2012 23:05:27 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta17.westchester.pa.mail.comcast.net with comcast id Dz5S1j00o07duvL3dz5T5P; Thu, 24 May 2012 23:05:27 +0000 Message-ID: <4FBEBEB6.7070504@alum.mit.edu> Date: Thu, 24 May 2012 19:05:26 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: clue@ietf.org References: <4FBDC407.5090902@nteczone.com> <7F2072F1E0DE894DA4B517B93C6A05852C457B1394@ESESSCMS0356.eemea.ericsson.se> , In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] Updates to CLUE information transport criteria from May 22 DT meeting X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 24 May 2012 23:05:42 -0000 Roni, IMO there has been a basic premise from the beginning that there is a three message exchange - capabilities/advertisement/selection. But there has been little investigation of the capabilities part, and so I sense some expect that the capabilities will be abandoned. We need to figure that out. There has also been some suggestion that we may need multiple transport mechanisms with differing characteristics - timing, size limitations, etc. That may not exactly fit the capabilities/advertisement/selection model well. And there is the recognition that SDP O/A must be part of the picture. But it also doesn't fit the capabilities/advertisement/selection model very well. We need to sort all of that out and reach some conclusion. The data model, and the classification of the characteristics of the data elements is intended to shed further light, to help get to a conclusion. Thanks, Paul On 5/24/12 5:09 PM, Roni even wrote: > Mary, > I am sorry but this is not a chicken and egg thing. > > This is a basic CLUE framework issue. If the view is that the provider will send advertisements based on the consumer capabilities or whether he will send advertisements based on his capabilities is a fundamental question that will have a major influence on the transport type. > Roni > > ________________________________________ > From: Mary Barnes [mary.ietf.barnes@gmail.com] > Sent: Thursday, May 24, 2012 22:11 > To: Roni even > Cc: Christer Holmberg; CLUE > Subject: Re: [clue] Updates to CLUE information transport criteria from May 22 DT meeting > > It's a chicken/egg thing. But, I think whether there are two or three > messages is slightly orthogonal. I can see that once we actually have > a data model and identify the criteria required to transport the > information to achieve the desired functionality that it will be > easier to decide what transport mechanism is appropriate. Some of > this was already considered in this draft: > http://www.ietf.org/id/draft-romanow-clue-sdp-usage-01.txt > > Mary. > > On Thu, May 24, 2012 at 1:57 PM, Roni even wrote: >> Hi, >> This is probably my bad English but I understood the subject as written. I will look again at the list including the topics I had since it looks to me that they are not related to the information but more to the transport. >> >> I think that the major issue here is that we need to say what messages are used to carry the information is it two or three messages. This will have a major impact on the transport since if we need three messages starting with a consumer capabilities this does not work well with offer answer. >> >> Roni >> >> ________________________________________ >> From: clue-bounces@ietf.org [clue-bounces@ietf.org] on behalf of Mary Barnes [mary.ietf.barnes@gmail.com] >> Sent: Thursday, May 24, 2012 18:08 >> To: Christer Holmberg >> Cc: CLUE >> Subject: Re: [clue] Updates to CLUE information transport criteria from May 22 DT meeting >> >> Yes, that was the intent - to characterize the requirements for the >> information to be exchanged. Then we can then match those with a >> signaling solution(s) that satisfy the criteria for each of the >> information elements that need to be exchanged. >> >> Mary. >> >> On Thu, May 24, 2012 at 3:48 AM, Christer Holmberg >> wrote: >>> Hi, >>> >>> At least my intention has been to cover all information that is going to be exchanged. >>> >>> Regards, >>> >>> Christer >>> >>> ________________________________________ >>> From: clue-bounces@ietf.org [clue-bounces@ietf.org] On Behalf Of Christian Groves [Christian.Groves@nteczone.com] >>> Sent: Thursday, May 24, 2012 8:15 AM >>> To: CLUE >>> Subject: Re: [clue] Updates to CLUE information transport criteria from May 22 DT meeting >>> >>> Hello, >>> >>> I'm a little bit puzzled what the aim of the list/exercise is. >>> Christer's original list appeared to be for determining the criteria to >>> select a transport for CLUE. The list below seems now to be on >>> individual data elements? Are we considering only CLUE data elements >>> which I would assume for a CLUE data model? or is the scope broader? A >>> broader scope appears to be suggested by mentioning information for SIP >>> establishment, SDP etc. >>> >>> Some specific comments below: >>> >>> The description of 3) on the expected frequency seems to be mixing how >>> often something will be sent and expected response time based on >>> signalling. Item 5) covers "delay". Should this be merged with 3) or >>> does the description of 3) need to be revised to remove the delay aspect? >>> >>> It would be good to get more information on 8). Are we talking about a >>> heterogeneous use case or a legacy use case? or? >>> >>> Regards, Christian >>> >>> On 24/05/2012 2:48 AM, Mary Barnes wrote: >>>> Per the thread on timing: >>>> http://www.ietf.org/mail-archive/web/clue/current/msg01346.html >>>> I have incorporated what I think were agreed in terms of the 3 >>>> categorizations that Marshall put forth in the item below. We would >>>> need to wordsmith the text to be specific to CLUE but I think the >>>> references to things like IPTV provide a useful >>>> reference/rationalization for the values. >>>> >>>> Ideally, if folks can provide any feedback no later than noon on >>>> Friday, May 25th, the folks doing the data model will have something >>>> to work from. >>>> >>>> Thanks, >>>> Mary. >>>> >>>> On Tue, May 22, 2012 at 11:55 AM, Mary Barnes >>>> wrote: >>>>> Hi all, >>>>> >>>>> This is a summary of updates proposed during today's design team >>>>> meeting, based on Christer's original proposal and Roni's suggested >>>>> additions: >>>>> http://www.ietf.org/mail-archive/web/clue/current/msg01433.html >>>>> >>>>> Note, this a very important thread of discussion as we really need >>>>> someone to step forward to take on detailing the data model and >>>>> evaluate each of the data elements against this criteria: >>>>> >>>>> 1) Whether signaling intermediaries (e.g. SBGs) need to have access to >>>>> the information - i.e.. whether information is relevant to routing >>>>> decisions, policies as to how to route, etc. >>>>> >>>>> -- Whether the CLUE information and the media description (SDP) need >>>>> to be in the same message. >>>>> >>>>> -- Whether the CLUE information and the media description (SDP) need >>>>> to use the same transport path. >>>>> >>>>> 2) The expected size of the information to be sent (i.e., estimate of bytes) >>>>> >>>>> 3) The expected frequency of the information to be sent: >>>> -- 30 msec. This is a video frame. Nothing of significance can >>>> happen faster, and some things, such as video switching, ideally would >>>> only take one frame. >>>> -- 200 msec. This was always viewed as the ideal IPTV channel change >>>> time (and a lot of work was done on IGMP to try and get there). This >>>> also happens to be a rough upper bound on non-noticeable RTTs, and so >>>> is a rough limit on how fast you can do things if those things >>>> require some sort of RT handshake / authorization / acknowledgement. >>>> It would be good to do many CLUE config changes in this >>>> time range - experience is that users will tolerate 200 msec of >>>> interruption or dead time, if something major changes. >>>> -- many seconds. Setting up a conference, changing basic conference >>>> parameters, etc., can take many seconds. Rebooting equipment can take >>>> many seconds. >>>> >>>>> 4) Whether the information is sent during session establishment, mid- >>>>> session and/or session termination. >>>>> >>>>> -- Information for SIP session establishment >>>>> >>>>> -- Information about CLUE, information about media, information to >>>>> establish media >>>>> >>>>> 5) What delay is acceptable for the information (i.e., CLUE data element) >>>>> >>>>> 6) Whether the information is sent as a notification, or whether some >>>>> kind of response is needed >>>>> >>>>> -- Does information need to be carried in a request and response or >>>>> >>>>> -- is it just necessary to be communicated one way >>>>> >>>>> 7) Whether the information needs to be delivered reliably (either >>>>> using a reliable transport mechanism, and/or some kind of >>>>> higher-level acknowledgement) >>>>> >>>>> 8) Whether the information is needed by a non-CLUE entity in order to >>>>> participate in a CLUE conference >>>>> >>>>> -- Not sure the intent here. Christer, can you please clarify what you >>>>> mean by non-CLUE. Also, are you talking about some sort of mapping or >>>>> is this a more theoretical question? >>>>> >>>>> >>>>> >>>>> Thanks, >>>>> Mary. >>>> _______________________________________________ >>>> clue mailing list >>>> clue@ietf.org >>>> https://www.ietf.org/mailman/listinfo/clue >>>> >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >> _______________________________________________ >> 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 > From Even.roni@huawei.com Thu May 24 16:11:06 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B2DA11E80A3 for ; Thu, 24 May 2012 16:11:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0-bgwLa6dA7g for ; Thu, 24 May 2012 16:11:02 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 4827F11E8081 for ; Thu, 24 May 2012 16:11:02 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AGM86911; Thu, 24 May 2012 19:11:02 -0400 (EDT) Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 24 May 2012 16:09:12 -0700 Received: from SZXEML413-HUB.china.huawei.com (10.82.67.152) by dfweml406-hub.china.huawei.com (10.193.5.131) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 24 May 2012 16:09:18 -0700 Received: from SZXEML536-MBX.china.huawei.com ([10.82.67.115]) by szxeml413-hub.china.huawei.com ([10.82.67.152]) with mapi id 14.01.0323.003; Fri, 25 May 2012 07:09:15 +0800 From: Roni even To: Paul Kyzivat , "clue@ietf.org" Thread-Topic: [clue] Updates to CLUE information transport criteria from May 22 DT meeting Thread-Index: AQHNOWxnghVzzhvxOUO+pSwi+0dtyJbYGu8AgABqWICAAMQ6Sf//f4EAgACmO7v//5s2AIAAhm7z Date: Thu, 24 May 2012 23:09:14 +0000 Message-ID: References: <4FBDC407.5090902@nteczone.com> <7F2072F1E0DE894DA4B517B93C6A05852C457B1394@ESESSCMS0356.eemea.ericsson.se> , , <4FBEBEB6.7070504@alum.mit.edu> In-Reply-To: <4FBEBEB6.7070504@alum.mit.edu> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.24.1.45] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [clue] Updates to CLUE information transport criteria from May 22 DT meeting X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 24 May 2012 23:11:06 -0000 Hi Paul, Some of the discussion going on the capture set entries claim that the adve= rtisement will include the capture scene entries relevant to the consumer. = If this is the case than the provider need to know more about the consumer. Roni ________________________________________ From: clue-bounces@ietf.org [clue-bounces@ietf.org] on behalf of Paul Kyziv= at [pkyzivat@alum.mit.edu] Sent: Friday, May 25, 2012 2:05 To: clue@ietf.org Subject: Re: [clue] Updates to CLUE information transport criteria from May= 22 DT meeting Roni, IMO there has been a basic premise from the beginning that there is a three message exchange - capabilities/advertisement/selection. But there has been little investigation of the capabilities part, and so I sense some expect that the capabilities will be abandoned. We need to figure that out. There has also been some suggestion that we may need multiple transport mechanisms with differing characteristics - timing, size limitations, etc. That may not exactly fit the capabilities/advertisement/selection model well. And there is the recognition that SDP O/A must be part of the picture. But it also doesn't fit the capabilities/advertisement/selection model very well. We need to sort all of that out and reach some conclusion. The data model, and the classification of the characteristics of the data elements is intended to shed further light, to help get to a conclusion. Thanks, Paul On 5/24/12 5:09 PM, Roni even wrote: > Mary, > I am sorry but this is not a chicken and egg thing. > > This is a basic CLUE framework issue. If the view is that the provider wi= ll send advertisements based on the consumer capabilities or whether he wil= l send advertisements based on his capabilities is a fundamental question t= hat will have a major influence on the transport type. > Roni > > ________________________________________ > From: Mary Barnes [mary.ietf.barnes@gmail.com] > Sent: Thursday, May 24, 2012 22:11 > To: Roni even > Cc: Christer Holmberg; CLUE > Subject: Re: [clue] Updates to CLUE information transport criteria from M= ay 22 DT meeting > > It's a chicken/egg thing. But, I think whether there are two or three > messages is slightly orthogonal. I can see that once we actually have > a data model and identify the criteria required to transport the > information to achieve the desired functionality that it will be > easier to decide what transport mechanism is appropriate. Some of > this was already considered in this draft: > http://www.ietf.org/id/draft-romanow-clue-sdp-usage-01.txt > > Mary. > > On Thu, May 24, 2012 at 1:57 PM, Roni even wrote: >> Hi, >> This is probably my bad English but I understood the subject as written.= I will look again at the list including the topics I had since it looks to= me that they are not related to the information but more to the transport. >> >> I think that the major issue here is that we need to say what messages a= re used to carry the information is it two or three messages. This will hav= e a major impact on the transport since if we need three messages starting = with a consumer capabilities this does not work well with offer answer. >> >> Roni >> >> ________________________________________ >> From: clue-bounces@ietf.org [clue-bounces@ietf.org] on behalf of Mary Ba= rnes [mary.ietf.barnes@gmail.com] >> Sent: Thursday, May 24, 2012 18:08 >> To: Christer Holmberg >> Cc: CLUE >> Subject: Re: [clue] Updates to CLUE information transport criteria from = May 22 DT meeting >> >> Yes, that was the intent - to characterize the requirements for the >> information to be exchanged. Then we can then match those with a >> signaling solution(s) that satisfy the criteria for each of the >> information elements that need to be exchanged. >> >> Mary. >> >> On Thu, May 24, 2012 at 3:48 AM, Christer Holmberg >> wrote: >>> Hi, >>> >>> At least my intention has been to cover all information that is going t= o be exchanged. >>> >>> Regards, >>> >>> Christer >>> >>> ________________________________________ >>> From: clue-bounces@ietf.org [clue-bounces@ietf.org] On Behalf Of Christ= ian Groves [Christian.Groves@nteczone.com] >>> Sent: Thursday, May 24, 2012 8:15 AM >>> To: CLUE >>> Subject: Re: [clue] Updates to CLUE information transport criteria from= May 22 DT meeting >>> >>> Hello, >>> >>> I'm a little bit puzzled what the aim of the list/exercise is. >>> Christer's original list appeared to be for determining the criteria to >>> select a transport for CLUE. The list below seems now to be on >>> individual data elements? Are we considering only CLUE data elements >>> which I would assume for a CLUE data model? or is the scope broader? A >>> broader scope appears to be suggested by mentioning information for SIP >>> establishment, SDP etc. >>> >>> Some specific comments below: >>> >>> The description of 3) on the expected frequency seems to be mixing how >>> often something will be sent and expected response time based on >>> signalling. Item 5) covers "delay". Should this be merged with 3) or >>> does the description of 3) need to be revised to remove the delay aspec= t? >>> >>> It would be good to get more information on 8). Are we talking about a >>> heterogeneous use case or a legacy use case? or? >>> >>> Regards, Christian >>> >>> On 24/05/2012 2:48 AM, Mary Barnes wrote: >>>> Per the thread on timing: >>>> http://www.ietf.org/mail-archive/web/clue/current/msg01346.html >>>> I have incorporated what I think were agreed in terms of the 3 >>>> categorizations that Marshall put forth in the item below. We would >>>> need to wordsmith the text to be specific to CLUE but I think the >>>> references to things like IPTV provide a useful >>>> reference/rationalization for the values. >>>> >>>> Ideally, if folks can provide any feedback no later than noon on >>>> Friday, May 25th, the folks doing the data model will have something >>>> to work from. >>>> >>>> Thanks, >>>> Mary. >>>> >>>> On Tue, May 22, 2012 at 11:55 AM, Mary Barnes >>>> wrote: >>>>> Hi all, >>>>> >>>>> This is a summary of updates proposed during today's design team >>>>> meeting, based on Christer's original proposal and Roni's suggested >>>>> additions: >>>>> http://www.ietf.org/mail-archive/web/clue/current/msg01433.html >>>>> >>>>> Note, this a very important thread of discussion as we really need >>>>> someone to step forward to take on detailing the data model and >>>>> evaluate each of the data elements against this criteria: >>>>> >>>>> 1) Whether signaling intermediaries (e.g. SBGs) need to have access t= o >>>>> the information - i.e.. whether information is relevant to routing >>>>> decisions, policies as to how to route, etc. >>>>> >>>>> -- Whether the CLUE information and the media description (SDP) ne= ed >>>>> to be in the same message. >>>>> >>>>> -- Whether the CLUE information and the media description (SDP) need >>>>> to use the same transport path. >>>>> >>>>> 2) The expected size of the information to be sent (i.e., estimate= of bytes) >>>>> >>>>> 3) The expected frequency of the information to be sent: >>>> -- 30 msec. This is a video frame. Nothing of significance can >>>> happen faster, and some things, such as video switching, ideally would >>>> only take one frame. >>>> -- 200 msec. This was always viewed as the ideal IPTV channel cha= nge >>>> time (and a lot of work was done on IGMP to try and get there). This >>>> also happens to be a rough upper bound on non-noticeable RTTs, and so >>>> is a rough limit on how fast you can do things if those things >>>> require some sort of RT handshake / authorization / acknowledgement. >>>> It would be good to do many CLUE config changes in this >>>> time range - experience is that users will tolerate 200 msec of >>>> interruption or dead time, if something major changes. >>>> -- many seconds. Setting up a conference, changing basic conferenc= e >>>> parameters, etc., can take many seconds. Rebooting equipment can take >>>> many seconds. >>>> >>>>> 4) Whether the information is sent during session establishment, m= id- >>>>> session and/or session termination. >>>>> >>>>> -- Information for SIP session establishment >>>>> >>>>> -- Information about CLUE, information about media, information to >>>>> establish media >>>>> >>>>> 5) What delay is acceptable for the information (i.e., CLUE data e= lement) >>>>> >>>>> 6) Whether the information is sent as a notification, or whether some >>>>> kind of response is needed >>>>> >>>>> -- Does information need to be carried in a request and response or >>>>> >>>>> -- is it just necessary to be communicated one way >>>>> >>>>> 7) Whether the information needs to be delivered reliably (either >>>>> using a reliable transport mechanism, and/or some kind of >>>>> higher-level acknowledgement) >>>>> >>>>> 8) Whether the information is needed by a non-CLUE entity in order to >>>>> participate in a CLUE conference >>>>> >>>>> -- Not sure the intent here. Christer, can you please clarify what yo= u >>>>> mean by non-CLUE. Also, are you talking about some sort of mapping o= r >>>>> is this a more theoretical question? >>>>> >>>>> >>>>> >>>>> Thanks, >>>>> Mary. >>>> _______________________________________________ >>>> clue mailing list >>>> clue@ietf.org >>>> https://www.ietf.org/mailman/listinfo/clue >>>> >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue= From Christian.Groves@nteczone.com Thu May 24 16:18:16 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F09A11E80B3 for ; Thu, 24 May 2012 16:18:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AoEwXIxsrDGQ for ; Thu, 24 May 2012 16:18:15 -0700 (PDT) Received: from ipmail06.adl2.internode.on.net (ipmail06-adl2.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:2:6]) by ietfa.amsl.com (Postfix) with ESMTP id 2FF1911E80A3 for ; Thu, 24 May 2012 16:18:14 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBAKfAvk920T+y/2dsb2JhbAANN7gHAQEBBAEBATUbGwoRCxgJFg8JAwIBAgEPBjAGDQYCAQGHewMWsWYNiU6KHmEkhSIDlieJaIdr Received: from ppp118-209-63-178.lns20.mel4.internode.on.net (HELO [127.0.0.1]) ([118.209.63.178]) by ipmail06.adl2.internode.on.net with ESMTP; 25 May 2012 08:48:12 +0930 Message-ID: <4FBEC1AE.5040808@nteczone.com> Date: Fri, 25 May 2012 09:18:06 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "clue@ietf.org" References: <4FBEC18D.4050301@nteczone.com> In-Reply-To: <4FBEC18D.4050301@nteczone.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] *Updated Consensus Call*: Add description text to a capture scene? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 24 May 2012 23:18:16 -0000 On 25/05/2012 9:17 AM, Christian Groves wrote: > 1) No > 2) Yes > 3) No > > Christian > > On 25/05/2012 7:57 AM, Mary Barnes wrote: >> At this point (2 hours shy of the deadline to express your opinion), >> there are a total of 8 responses answering the questions: >> 1) Yes (1), No (7) >> 2) Yes (8), No (0) >> 3) Yes (0), No (8) >> >> Again, please respond by 5pm Pacific today, so that the decision can >> be reflected in the next version of the framework document. If the >> text string is agreed to be added (as it seems likely), it will have >> to support multiple languages as Roni highlighted. >> >> Thanks, >> Mary. >> >> On Tue, May 22, 2012 at 12:10 PM, Mary Barnes >> wrote: >>> Per Marshall's feedback, I am reposing the questions to consider the >>> optional aspect (which is what I think we have been discussing, but >>> just to be clear). >>> >>> 1) Do you agree that we should add a mandatory element with human >>> readable text to the capture scene? >>> 2) Do you agree that we should add an optional element with human >>> readable text to the capture scene? >>> 3) Do you agree that we should not add any optional or mandatory human >>> readable text to the capture scene? >>> >>> Thanks, >>> Mary. >>> >>> On Tue, May 22, 2012 at 11:36 AM, Mary Barnes >>> wrote: >>>> Resending with a new Subject just to make sure folks pick up on >>>> this as a >>>> Consensus call. >>>> >>>> On Tue, May 22, 2012 at 11:35 AM, Mary >>>> Barnes >>>> wrote: >>>>> Hi all, >>>>> >>>>> Per the design team meeting this morning, we are doing a consensus >>>>> call on >>>>> the question as to whether human readable text string should be >>>>> added to the >>>>> capture scene. >>>>> >>>>> Note that while this came up during discussion of Ticket #8 in a >>>>> previous >>>>> meeting, it does not impact the state of Ticket #8 which remains >>>>> open: >>>>> http://trac.tools.ietf.org/wg/clue/trac/ticket/8 (How consumer >>>>> differentiates between multiple capture scenes) >>>>> >>>>> So, if folks could please respond to the following question with a >>>>> "Yes" >>>>> or "No": >>>>> >>>>> Should a human readable text string be added to the capture scene >>>>> in the >>>>> framework document? >>>>> >>>>> It would also be helpful (but not required for consensus) if folks >>>>> could >>>>> provide a brief statement justifying their response for the WG >>>>> members that >>>>> did not hear the discussion on today's call. >>>>> >>>>> The consensus call closes on Thursday at 5pm Pacific. >>>>> >>>>> Thanks, >>>>> Mary >>>>> CLUE WG co-chair >>>>> >>>>> >>>>> >>>>> >>>>> On Fri, May 18, 2012 at 11:56 AM, Duckworth, Mark >>>>> wrote: >>>>>> Regarding Ticket #8 - How consumer differentiates between multiple >>>>>> capture scenes. >>>>>> We discussed this a bit on the list, and on the April 10 phone >>>>>> meeting. >>>>>> I think the group agreed we should add a human readable text >>>>>> string >>>>>> attribute to a capture scene. >>>>>> >>>>>> Here is a proposal for adding text to the framework document section >>>>>> 6.2.1 Capture scene attributes: >>>>>> >>>>>> Description attribute >>>>>> >>>>>> The description attribute is a human readable text string which >>>>>> describes >>>>>> the capture scene. A provider that advertises multiple capture >>>>>> scenes may >>>>>> use different descriptions to differentiate between them. >>>>>> >>>>>> >>>>>> Do we also want to add a similar description attribute to a media >>>>>> capture? >>>>>> >>>>>> Mark Duckworth >>>>>> _______________________________________________ >>>>>> 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 >> From Christian.Groves@nteczone.com Thu May 24 16:21:17 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A08621F84E4 for ; Thu, 24 May 2012 16:21:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LxzJXlwKWquO for ; Thu, 24 May 2012 16:21:16 -0700 (PDT) Received: from ipmail06.adl2.internode.on.net (ipmail06-adl2.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:2:6]) by ietfa.amsl.com (Postfix) with ESMTP id A9C6A21F8476 for ; Thu, 24 May 2012 16:21:15 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBANLBvk920T+y/2dsb2JhbAANN7gHAQEBBAEBATUbFAEGCgEQCxEEAQEBCRYPCQMCAQIBDwYoCAYNAQUCAQEFhgiBbgMWsWgNiU6KHmEVBYUsA6APh2uBRQg Received: from ppp118-209-63-178.lns20.mel4.internode.on.net (HELO [127.0.0.1]) ([118.209.63.178]) by ipmail06.adl2.internode.on.net with ESMTP; 25 May 2012 08:51:14 +0930 Message-ID: <4FBEC263.8060304@nteczone.com> Date: Fri, 25 May 2012 09:21:07 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Christer Holmberg References: , <4FBDC407.5090902@nteczone.com> <7F2072F1E0DE894DA4B517B93C6A05852C457B1394@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C457B1394@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: CLUE Subject: Re: [clue] Updates to CLUE information transport criteria from May 22 DT meeting X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 24 May 2012 23:21:17 -0000 Hello Christer, Cover all the information in the data model or cover all the information against the criteria? Also do you have any information on 8 (see my question below)? Regards, Christian On 24/05/2012 6:48 PM, Christer Holmberg wrote: > Hi, > > At least my intention has been to cover all information that is going to be exchanged. > > Regards, > > Christer > > ________________________________________ > From: clue-bounces@ietf.org [clue-bounces@ietf.org] On Behalf Of Christian Groves [Christian.Groves@nteczone.com] > Sent: Thursday, May 24, 2012 8:15 AM > To: CLUE > Subject: Re: [clue] Updates to CLUE information transport criteria from May 22 DT meeting > > Hello, > > I'm a little bit puzzled what the aim of the list/exercise is. > Christer's original list appeared to be for determining the criteria to > select a transport for CLUE. The list below seems now to be on > individual data elements? Are we considering only CLUE data elements > which I would assume for a CLUE data model? or is the scope broader? A > broader scope appears to be suggested by mentioning information for SIP > establishment, SDP etc. > > Some specific comments below: > > The description of 3) on the expected frequency seems to be mixing how > often something will be sent and expected response time based on > signalling. Item 5) covers "delay". Should this be merged with 3) or > does the description of 3) need to be revised to remove the delay aspect? > > It would be good to get more information on 8). Are we talking about a > heterogeneous use case or a legacy use case? or? > > Regards, Christian > > On 24/05/2012 2:48 AM, Mary Barnes wrote: >> Per the thread on timing: >> http://www.ietf.org/mail-archive/web/clue/current/msg01346.html >> I have incorporated what I think were agreed in terms of the 3 >> categorizations that Marshall put forth in the item below. We would >> need to wordsmith the text to be specific to CLUE but I think the >> references to things like IPTV provide a useful >> reference/rationalization for the values. >> >> Ideally, if folks can provide any feedback no later than noon on >> Friday, May 25th, the folks doing the data model will have something >> to work from. >> >> Thanks, >> Mary. >> >> On Tue, May 22, 2012 at 11:55 AM, Mary Barnes >> wrote: >>> Hi all, >>> >>> This is a summary of updates proposed during today's design team >>> meeting, based on Christer's original proposal and Roni's suggested >>> additions: >>> http://www.ietf.org/mail-archive/web/clue/current/msg01433.html >>> >>> Note, this a very important thread of discussion as we really need >>> someone to step forward to take on detailing the data model and >>> evaluate each of the data elements against this criteria: >>> >>> 1) Whether signaling intermediaries (e.g. SBGs) need to have access to >>> the information - i.e.. whether information is relevant to routing >>> decisions, policies as to how to route, etc. >>> >>> -- Whether the CLUE information and the media description (SDP) need >>> to be in the same message. >>> >>> -- Whether the CLUE information and the media description (SDP) need >>> to use the same transport path. >>> >>> 2) The expected size of the information to be sent (i.e., estimate of bytes) >>> >>> 3) The expected frequency of the information to be sent: >> -- 30 msec. This is a video frame. Nothing of significance can >> happen faster, and some things, such as video switching, ideally would >> only take one frame. >> -- 200 msec. This was always viewed as the ideal IPTV channel change >> time (and a lot of work was done on IGMP to try and get there). This >> also happens to be a rough upper bound on non-noticeable RTTs, and so >> is a rough limit on how fast you can do things if those things >> require some sort of RT handshake / authorization / acknowledgement. >> It would be good to do many CLUE config changes in this >> time range - experience is that users will tolerate 200 msec of >> interruption or dead time, if something major changes. >> -- many seconds. Setting up a conference, changing basic conference >> parameters, etc., can take many seconds. Rebooting equipment can take >> many seconds. >> >>> 4) Whether the information is sent during session establishment, mid- >>> session and/or session termination. >>> >>> -- Information for SIP session establishment >>> >>> -- Information about CLUE, information about media, information to >>> establish media >>> >>> 5) What delay is acceptable for the information (i.e., CLUE data element) >>> >>> 6) Whether the information is sent as a notification, or whether some >>> kind of response is needed >>> >>> -- Does information need to be carried in a request and response or >>> >>> -- is it just necessary to be communicated one way >>> >>> 7) Whether the information needs to be delivered reliably (either >>> using a reliable transport mechanism, and/or some kind of >>> higher-level acknowledgement) >>> >>> 8) Whether the information is needed by a non-CLUE entity in order to >>> participate in a CLUE conference >>> >>> -- Not sure the intent here. Christer, can you please clarify what you >>> mean by non-CLUE. Also, are you talking about some sort of mapping or >>> is this a more theoretical question? >>> >>> >>> >>> Thanks, >>> Mary. >> _______________________________________________ >> 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 From mary.ietf.barnes@gmail.com Fri May 25 12:22:17 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB97B21F877F for ; Fri, 25 May 2012 12:22:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.606 X-Spam-Level: X-Spam-Status: No, score=-103.606 tagged_above=-999 required=5 tests=[AWL=-0.008, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gy9u3oA4D7-y for ; Fri, 25 May 2012 12:22:16 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 99E7621F873A for ; Fri, 25 May 2012 12:22:16 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so1069240vbb.31 for ; Fri, 25 May 2012 12:22:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=YfMu0EjCS4pEJ1MBiSDoaymGIpasQ1oIv4Q/6F8D4Yk=; b=Vx7YF1XTxOVeCq833GUdfsppG5ldhFKHxipCBJzfdpsnwmwFcJwN4HrXt50CGiKbQ/ H5p7N38PX3NFlDkyS9wD9MK4oWmq1eeJb2aWS2JnTbZ/dcpd60XzWN8xLINmXsxqdmks dsGdJFL6HOds0A7oNXQoy0cnTSuScihwS+9c1OqEE1EuCJb6iH24LfPHVZI+K0fBQBox YvbHVr/H08t8KgiR9kHV/l1mhga8sdPy6vWuxUEWm/hpQt73owfCO3K+xvoaUSRQL0og HBp5pZg+LvuPbebvVlgdpgdPgWhVK0OBBhVomGiXiWQHZXgEnLXxdyPyQs4B7b7MmwFu yZIg== MIME-Version: 1.0 Received: by 10.52.97.230 with SMTP id ed6mr54367vdb.65.1337973736127; Fri, 25 May 2012 12:22:16 -0700 (PDT) Received: by 10.52.22.143 with HTTP; Fri, 25 May 2012 12:22:16 -0700 (PDT) In-Reply-To: References: Date: Fri, 25 May 2012 14:22:16 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=20cf307ac43742be3404c0e14970 Subject: Re: [clue] *Updated Consensus Call*: Add description text to a capture scene? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 25 May 2012 19:22:17 -0000 --20cf307ac43742be3404c0e14970 Content-Type: text/plain; charset=ISO-8859-1 There was clear consensus to add an optional element with human readable text to the capture scene in the framework document. The element will have a language attribute. For completeness, these were the totals: 1) Yes (1), No (8) 2) Yes (9), No (0) 3) Yes (0), No (0) Thanks, Mary. On Thu, May 24, 2012 at 4:57 PM, Mary Barnes wrote: > At this point (2 hours shy of the deadline to express your opinion), > there are a total of 8 responses answering the questions: > 1) Yes (1), No (7) > 2) Yes (8), No (0) > 3) Yes (0), No (8) > > Again, please respond by 5pm Pacific today, so that the decision can > be reflected in the next version of the framework document. If the > text string is agreed to be added (as it seems likely), it will have > to support multiple languages as Roni highlighted. > > Thanks, > Mary. > > On Tue, May 22, 2012 at 12:10 PM, Mary Barnes > wrote: > > Per Marshall's feedback, I am reposing the questions to consider the > > optional aspect (which is what I think we have been discussing, but > > just to be clear). > > > > 1) Do you agree that we should add a mandatory element with human > > readable text to the capture scene? > > 2) Do you agree that we should add an optional element with human > > readable text to the capture scene? > > 3) Do you agree that we should not add any optional or mandatory human > > readable text to the capture scene? > > > > Thanks, > > Mary. > > > > On Tue, May 22, 2012 at 11:36 AM, Mary Barnes > > wrote: > >> Resending with a new Subject just to make sure folks pick up on this as > a > >> Consensus call. > >> > >> On Tue, May 22, 2012 at 11:35 AM, Mary Barnes < > mary.ietf.barnes@gmail.com> > >> wrote: > >>> > >>> Hi all, > >>> > >>> Per the design team meeting this morning, we are doing a consensus > call on > >>> the question as to whether human readable text string should be added > to the > >>> capture scene. > >>> > >>> Note that while this came up during discussion of Ticket #8 in a > previous > >>> meeting, it does not impact the state of Ticket #8 which remains open: > >>> http://trac.tools.ietf.org/wg/clue/trac/ticket/8 (How consumer > >>> differentiates between multiple capture scenes) > >>> > >>> So, if folks could please respond to the following question with a > "Yes" > >>> or "No": > >>> > >>> Should a human readable text string be added to the capture scene in > the > >>> framework document? > >>> > >>> It would also be helpful (but not required for consensus) if folks > could > >>> provide a brief statement justifying their response for the WG members > that > >>> did not hear the discussion on today's call. > >>> > >>> The consensus call closes on Thursday at 5pm Pacific. > >>> > >>> Thanks, > >>> Mary > >>> CLUE WG co-chair > >>> > >>> > >>> > >>> > >>> On Fri, May 18, 2012 at 11:56 AM, Duckworth, Mark > >>> wrote: > >>>> > >>>> Regarding Ticket #8 - How consumer differentiates between multiple > >>>> capture scenes. > >>>> We discussed this a bit on the list, and on the April 10 phone > meeting. > >>>> I think the group agreed we should add a human readable text string > >>>> attribute to a capture scene. > >>>> > >>>> Here is a proposal for adding text to the framework document section > >>>> 6.2.1 Capture scene attributes: > >>>> > >>>> Description attribute > >>>> > >>>> The description attribute is a human readable text string which > describes > >>>> the capture scene. A provider that advertises multiple capture > scenes may > >>>> use different descriptions to differentiate between them. > >>>> > >>>> > >>>> Do we also want to add a similar description attribute to a media > >>>> capture? > >>>> > >>>> Mark Duckworth > >>>> _______________________________________________ > >>>> clue mailing list > >>>> clue@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/clue > >>> > >>> > >> > --20cf307ac43742be3404c0e14970 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable There was clear consensus to add an=A0optional element with human
readab= le text to the capture scene in the framework document. =A0The element will= have a language attribute.

For completeness, these were= the totals:
1) Yes (1), No (8)
2) Yes (9), No (0)
3) Yes (0), = No (0)

Thanks,
Mary.

On Thu, May 24, 2012 at 4:57 PM, Mary Barnes <mary.ietf.barnes@gmail.com> wrote:
At this point (2 hours shy of the deadline t= o express your opinion),
there are a total of 8 responses answering the questions:
1) Yes (1), No (7)
2) Yes (8), No (0)
3) Yes (0), No (8)

Again, please respond by 5pm Pacific today, so that the decision can
be reflected in the next version of the framework document. =A0If the
text string is agreed to be added (as it seems likely), it will have
to support multiple languages as Roni highlighted.

Thanks,
Mary.

On Tue, May 22, 2012 at 12:10 PM, Mary Barnes
<mary.ietf.barnes@gmail.co= m> wrote:
> Per Marshall's feedback, I am reposing the questions to consider t= he
> optional aspect (which is what I think we have been discussing, but > just to be clear).
>
> 1) Do you agree that we should add a mandatory element with human
> readable text to the capture scene?
> 2) Do you agree that we should add an optional element with human
> readable text to the capture scene?
> 3) Do you agree that we should not add any optional or mandatory human=
> readable text to the capture scene?
>
> Thanks,
> Mary.
>
> On Tue, May 22, 2012 at 11:36 AM, Mary Barnes
> <mary.ietf.barnes@gma= il.com> wrote:
>> Resending with a new Subject just to make sure folks pick up on th= is as a
>> Consensus call.
>>
>> On Tue, May 22, 2012 at 11:35 AM, Mary Barnes <mary.ietf.barnes@gmail.com>
>> wrote:
>>>
>>> Hi all,
>>>
>>> Per the design team meeting this morning, we are doing a conse= nsus call on
>>> the question as to whether human readable text string should b= e added to the
>>> capture scene.
>>>
>>> Note that while this came up during discussion of Ticket #8 in= a previous
>>> meeting, it does not impact the state of Ticket #8 which remai= ns open:
>>> http://trac.tools.ietf.org/wg/clue/trac/ticket/8 (How = consumer
>>> differentiates between multiple capture scenes)
>>>
>>> So, if folks could please respond to the following question wi= th a "Yes"
>>> or "No":
>>>
>>> Should a human readable text string be added to the capture sc= ene in the
>>> framework document?
>>>
>>> It would also be helpful (but not required for consensus) if f= olks could
>>> provide a brief statement justifying their response for the WG= members that
>>> did not hear the discussion on today's call.
>>>
>>> The consensus call closes on Thursday at 5pm Pacific.
>>>
>>> Thanks,
>>> Mary
>>> CLUE WG co-chair
>>>
>>>
>>>
>>>
>>> On Fri, May 18, 2012 at 11:56 AM, Duckworth, Mark
>>> <Mark.Duckwor= th@polycom.com> wrote:
>>>>
>>>> Regarding Ticket #8 - How consumer differentiates between = multiple
>>>> capture scenes.
>>>> We discussed this a bit on the list, and on the April 10 p= hone meeting.
>>>> =A0I think the group agreed we should add a human readable= text string
>>>> attribute to a capture scene.
>>>>
>>>> Here is a proposal for adding text to the framework docume= nt section
>>>> 6.2.1 Capture scene attributes:
>>>>
>>>> Description attribute
>>>>
>>>> The description attribute is a human readable text string = which describes
>>>> the capture scene. =A0A provider that advertises multiple = capture scenes may
>>>> use different descriptions to differentiate between them.<= br> >>>>
>>>>
>>>> Do we also want to add a similar description attribute to = a media
>>>> capture?
>>>>
>>>> Mark Duckworth
>>>> _______________________________________________
>>>> clue mailing list
>>>> clue@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/clue
>>>
>>>
>>

--20cf307ac43742be3404c0e14970-- From pkyzivat@alum.mit.edu Fri May 25 12:55:39 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D8AD21F87AF for ; Fri, 25 May 2012 12:55:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[AWL=-0.087, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QP7XrfgS5ULz for ; Fri, 25 May 2012 12:55:37 -0700 (PDT) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [76.96.62.40]) by ietfa.amsl.com (Postfix) with ESMTP id ED1DD21F87A1 for ; Fri, 25 May 2012 12:55:36 -0700 (PDT) Received: from omta14.westchester.pa.mail.comcast.net ([76.96.62.60]) by qmta04.westchester.pa.mail.comcast.net with comcast id EKuc1j0021HzFnQ54KvcrB; Fri, 25 May 2012 19:55:36 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta14.westchester.pa.mail.comcast.net with comcast id EKvb1j00K07duvL3aKvbhs; Fri, 25 May 2012 19:55:35 +0000 Message-ID: <4FBFE3B6.3000103@alum.mit.edu> Date: Fri, 25 May 2012 15:55:34 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: clue@ietf.org References: <4F846AE0.4010700@alum.mit.edu> In-Reply-To: <4F846AE0.4010700@alum.mit.edu> Content-Type: multipart/mixed; boundary="------------010001090106050107060204" Subject: Re: [clue] [ticket#10] Does framework provide sufficient info for receiver? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 25 May 2012 19:55:39 -0000 This is a multi-part message in MIME format. --------------010001090106050107060204 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 4/10/12 1:16 PM, Paul Kyzivat wrote: Following up on this thread, I promised to write up some use cases demonstrating this issue. It turned out to take a lot more time than I expected, and it also got bigger than I expected. This shouldn't be discussed in an email, but I want to get *something* out so I can get feedback if this is useful to pursue further. If so I'll turn it into a draft. Thanks, Paul --------------010001090106050107060204 Content-Type: text/plain; charset=UTF-8; name="draft-kyzivat-clue-extended-use-cases.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-kyzivat-clue-extended-use-cases.txt" The following is a start at a set of use cases addressing interoperation between CLUE endpoints and MCUs with varying characteristics. This is far from exhaustive, but it attempts to investigate a number of diverse cases that present difficulties. The goal here is to identify where added information is needed to make things work. Disclaimers: - I am only considering video. Similar issues exist for audio, but perhaps not so severe and the solutions may be different. - advertisements here don't take into account the capabilities of the other endpoint. It remains to consider cases where a capabilities message is used to condition the advertiser on what its useful to advertise. - I've enumerated five types of rooms. While I've covered all the point to point cases between them, I've only covered a few of the MCU cases. - I've only touched on the possible variations in MCU behavior. - Floor control needs more consideration This has turned out to be much bigger than I first thought it would be. Its really too big to cover well in an email. I should reformat this as a draft. But before I go to the work of doing that I'd like to get some initial feedback whether this is going in a useful direction. First some definitions: The video-scene-entry-size is the number of video captures in a scene entry. The scene-minimum-video-size is the smallest video-scene-entry-size over all the scene entries in a scene that contain any video captures. (Or zero if there are no video captures in the scene.) The scene-maximum-video-size is the largest video-scene-entry-size over all the scene entries in a scene that contain any video captures. (Or zero if there are no video captures in the scene.) Problems mapping advertisements to equipment: PROBLEM-1: An endpoint is presented with a difficult problem if it receives an advertisement where the sum over all scenes of the scene-minimum-video-size exceeds the number of available video devices. (A degenerate form of this is when the number of scenes containing video exceeds the number of available video devices.) In this case the endpoint must compose or switch some of the video captures, or simply drop some, in order to get to a number compatible with the available display devices. The question then is whether there is sufficient information available to make a good choice of what to do. This issue mostly occurs when multiple scenes are advertised, but it can occur with a single scene if there is no scene entry with a single video capture. PROBLEM-2: If the endpoint doesn't have PROBLEM-1, there may be a lesser problem if the sum over all scenes of the scene-maximum-video-size exceeds the number of available video devices, and there is no selection of a single scene entry from each scene that in aggregate requires exactly the number of available video devices. In this case it's possible to display all the scenes, but there is more/better information to display and available equipment to display it if a suitable selection can be made. Both of these problems can exist for rooms receiving advertisements from either another room or an MCU. MCUs have a similar, but harder problem when deciding how to consolidate the advertisements they receive into an advertisement to offer. The MCU has to decide how many scenes to advertise, how many different entries to put in each scene, what captures to associate with each scene entry, mapping to encoders, etc. In some sense it is faced with the same problem that an endpoint would, but for many different endpoint configurations. One potential way out of this is for the source device to include only a single scene in its advertisements, and to always include scene entries having every number of video captures from one up to the maximum number of video captures required to display everything. But that could be a larger burden than the sending device is willing/able to bear. The primary (only?) reason for multiple scenes is for captures that don't share a common coordinate space. A single room will likely only have a single coordinate space for the captures with a single content attribute value. In particular, there may be several captures with content 'main'. But captures with differing content values may not naturally fit into a single coordinate space. E.g. presentations (content 'slides') may come from a computer and not have any specific coordinate relationship to 'main'. This may also be true for sign language, speaker, etc. Of course they can be *mapped* into a single coordinate space, but that may imply an unnecessary relationship to the recipient, and may complicate subsequent mapping by the recipient onto equipment with differing geometry. All of this is pretty abstract. The use cases below expose these things in tangible ways. Each use case involves two or more rooms, each behaving in a particular way. Each room corresponds to a particular room type. The following room types are used in one or more of the use cases. ROOM TYPES: Alpha: each room has three cameras and three displays. There is no provision for users to supply presentations. Beta: each room has three cameras and four displays. The controller for the room allows the users in the room to connect their personal computers and provide a presentation. When a presentation is coming from a computer in the room, the room controller dedicates one of the displays to the presentation. The room's advertisement has a single scene. The presentation is assigned coordinates in the coordinate system of the room scene - the coordinates of the local monitor on which it is displayed. When presenting, the preferred scene entry has four captures, one each for the three cameras and one for the presentation. When not presenting, the preferred scene entry has only three captures. In either case there is also another scene entry with a single composed video capture. Gamma: each room has three cameras and displays visible to all participants in the room. There also is a private workstation for each participant, connected to the local room controller. A participant can connect his workstation to an application and request that it be presented as part of the clue session. The room controller can also send a capture for display on each of the workstations in the room. The room's advertisement has two scenes - one for the cameras and one for a capture containing the presentation. (The presentation scene is only advertised when presenting.) The preferred entry in the main scene has three captures, one each for the three cameras. It also includes another scene entry with a single video capture containing a composition of the three. The presentation scene, when advertised, contains the single presentation capture. Delta: each room has two cameras and three displays. The users in the room have computers that can connect to a webex-like system for presentation sharing, viewing, and floor control. The room advertises a single scene. The primary entry has two captures, one for each camera. There is another entry with a single capture containing a composition of the two. Epsilon: is similar to Delta. The difference is that users have computers that support a subset of CLUE and BFCP. They can connect to another CLUE server (MCU) and advertise a single scene with a single presentation capture that is derived locally from whatever is to be presented. They use BFCP for floor control in order to get the right to present. When receiving a clue advertisement, they select and display a single presentation capture. USE CASES In the following use cases, individual rooms are denoted by a room type and a number, such as Alpha1 and Epsilon2. _________________________________ Alpha-Alpha) Point to point CLUE session between room Alpha1 and room Alpha2. Each room can display the preferred scene entry from the single scene in a natural way without special mappings. _________________________________ Beta-Beta) Point to point CLUE session between room Beta1 and room Beta2. Different people take turns supplying presentation material from their individual computers. Floor control is ad hoc - only one presentation capture is delivered to the room controller at any one time. Each room can display the preferred scene entry from the single scene in a natural way without special mappings. _________________________________ Gamma-Gamma) Point to point CLUE session between rooms Gamma1 and Gamma2. When Gamma1 is presenting, it advertises both the camera scene and the presentation scene, while Gamma2 only advertises a camera scene. Each room maps the captures from the other's main camera capture scene entry to its main displays. Each room controller, when it has a presentation capture coming from the peer, maps it to all the local workstations in the room. When a participant in a room is presenting, the room controller sends the presentation to all the other workstations in the room, in addition to advertising it to the other room. _________________________________ Delta-Delta) Point to point CLUE session between rooms Delta1 and Delta2. Each room can display the preferred scene entry from the single scene in a natural way without special mappings. The participants connect their individual computers to a webex-like conference for sharing and viewing presentations. The rooms are completely oblivious to this presentation sharing. _________________________________ Epsilon-Epsilon) Point to point CLUE session between rooms Epsilon1 and Epsilon2. Because there is no MCU, the users have no place to connect their computers for presentation sharing. So there is no presentation support. _________________________________ Alpha-Beta) Point to point CLUE session between room Alpha1 and room Beta2. Different people in Beta2 take turns supplying presentation material from their individual computers. Floor control is ad hoc - only one presentation capture is delivered to the room controller at any one time. When room Beta2 is not advertising a presentation room Alpha1 can display the three main camera captures from Alpha1 on its three monitors. But when room Beta2 is also advertising a presentation, room Alpha1 can't map all four captures from the preferred scene entry. It can choose the scene entry with a single capture, plus the presentation. But then it is getting a suboptimal rendition and is not using all of its displays. Room Alpha1 could display the single composed capture plus one of the captures from the preferred scene, but it's not evident how it would decide which one. If it is sufficiently capable, room Alpha1 could select all the captures from the preferred scene entry and do its own composition to fit onto three monitors. _________________________________ Alpha-Gamma) Point to point CLUE session between rooms Alpha1 and Gamma2. This is similar to Gamma-Gamma except that room Alpha1 has no local workstations. When room Gamma2 is not advertising a presentation room Alpha1 can display the three main camera captures from Gamma2 on its three monitors. But when room Gamma2 is also advertising a presentation, room Alpha1 can't directly map all four captures to it's three monitors. It can choose the main scene entry with a single capture and display it on one monitor, and display the presentation capture on another monitor. But then it is wasting one of its monitors. Room Alpha1 could display the single composed capture plus one of the captures from the preferred scene, but it's not evident how it would decide which one. If it is sufficiently capable, room Alpha1 could select all the captures from the preferred scene entry and do its own composition to fit onto three monitors. _________________________________ Alpha-Delta) Point to point CLUE session between rooms Alpha1 and Delta2. Each room can display the preferred scene entry from the single scene in a natural way without special mappings. The participants in Delta2 can share presentations with one another via a webex-like conference. But the participants in Alpha1 have no visibility to the presentations. _________________________________ Alpha-Epsilon) Point to point CLUE session between rooms Alpha1 and Epsilon2. Because there is no MCU, the users in Epsilon2 have no place to connect their computers for presentation sharing. So there is no presentation support. _________________________________ Beta-Gamma) Point to point CLUE session between rooms Beta1 and Gamma2. When nobody is presenting each room can easily map the captures in the preferred entry of the single scene to its displays. When room Beta1 is presenting, it has a local display for its presentation, while also presenting the three captures from Gamma2. Gamma2 can display the three main captures on its shared displays. It can send the presentation capture to the workstations in the room. When room Gamma2 is presenting, it sends its own presentation to the workstations in the room that aren't presenting, and the three main captures from Beta1 to its shared displays. Beta1 can map the three camera captures from Gamma2 to three of its displays and the presentation capture to its other display. _________________________________ Beta-Delta) Point to point CLUE session between rooms Beta1 and Delta2. When nobody is presenting each room can easily map the captures in the preferred entry of the single scene to its displays. When room Beta1 is presenting, it has a local display for its presentation, while presenting the two captures from Delta2. Room Delta2 doesn't have sufficient displays to map all four captures from Beta1's preferred scene entry. It can choose the main scene entry with a single capture and display it on one monitor, and display the presentation capture on another monitor. But then it is wasting one of its monitors. When a user in room Delta2 is presenting, this is invisible to room Beta1 and its users. _________________________________ Beta-Epsilon) Point to point CLUE session between rooms Beta1 and Epsilon2. When nobody is presenting each room can easily map the captures in the preferred entry of the single scene to its displays. When room Beta1 is presenting, it has a local display for its presentation, while presenting the two captures from Epsilon2. Room Epsilon2 doesn't have sufficient displays to map all four captures from Beta1's preferred scene entry. It can choose the main scene entry with a single capture and display it on one monitor, and display the presentation capture on another monitor. But then it is wasting one of its monitors. Because there is no MCU, the users in room Epsilon2 have no place to connect their computers for presentation sharing. So there is no presentation support for them. _________________________________ Gamma-Delta) Point to point CLUE session between rooms Gamma1 and Delta2. When nobody is presenting each room can easily map the captures in the preferred entry of the single scene to its displays. When a participant in room Gamma1 is presenting, the room controller sends the presentation to all the other workstations in the room, in addition to advertising it to Delta2. Room Delta2 doesn't have sufficient displays to map all the captures from the preferred scene entries of Gamma1's two advertised scenes. It can choose the main scene entry with a single capture and display it on one monitor, and display the presentation capture on another monitor. But then it is wasting one of its monitors. When a user in room Delta2 is presenting, this is invisible to room Gamma1 and its users. _________________________________ Gamma-Epsilon) Point to point CLUE session between rooms Gamma1 and Epsilon2. When nobody is presenting each room can easily map the captures in the preferred entry of the single scene to its displays. When a participant in room Gamma1 is presenting, the room controller sends the presentation to all the other workstations in the room, in addition to advertising it to Epsilon2. Room Epsilon2 doesn't have sufficient displays to map all the captures from the preferred scene entries of Gamma1's two advertised scenes. It can choose the main scene entry with a single capture and display it on one monitor, and display the presentation capture on another monitor. But then it is wasting one of its monitors. Because there is no MCU, the users in room Epsilon2 have no place to connect their computers for presentation sharing. So there is no presentation support for them. _________________________________ Delta-Epsilon) Point to point CLUE session between rooms Delta1 and Epsilon2. When nobody is presenting each room can easily map the captures in the preferred entry of the single scene to its displays. When a user in room Delta1 is presenting, this is invisible to room Epsilon2 and its users. Because there is no MCU, the users in room Epsilon2 have no place to connect their computers for presentation sharing. So there is no presentation support for them. _________________________________ Alpha-MCU-Delta) CLUE and webex-like conference between Alpha1 and Delta2. The MCU presents a CLUE interface to the two rooms and a webex-like interface to the participant computers in the two rooms. The MCU selects the preferred entry from the single scene advertises by each room, so it has three captures from Alpha1 and two captures from Delta2. In addition, if someone is sharing via the webex interface it turns that into a presentation capture. Toward Alpha1 it advertises two scenes: one for the captures from Delta2 and one for the presentation. It includes one scene entry with the two captures from Delta2, and one entry with a single composed capture. Toward Delta2 it also advertises two scenes: one for the captures from Alpha1 and one for the presentation. It includes one scene entry with the three captures from Alpha1, and one entry with a single composed capture. Room Alpha1 can map the two captures from the primary scene (from Delta2's cameras) and the presentation stream to its three displays. Room Delta2 doesn't have enough displays to map all three captures from Alpha1's cameras and the presentation capture. If it knows the participants can see the presentation via their computers then it can map the other three captures to its displays. If not, then it will probably need to use one screen for the presentation, and select the composed entry for display on one of its other displays. (It is also possible to have an MCU that has no webex-like interface, and a separate webex-like conference server. This will work equally well in this case, but won't work well in some of the other cases.) _________________________________ Epsilon-MCU-Epsilon) CLUE conference between Epsilon1 and Epsilon2 and the computers of the users in each. The MCU presents a CLUE interface to the two rooms and the user's computers. It also supports a BFCP interface for requesting the presentation floor. The MCU selects the preferred entry from the single scene advertised by each room, so it has two captures from each of Epsilon1 and Epsilon2. In addition, if the presentation floor has been requested via BFCP, then it selects the presentation capture advertised by that endpoint. Toward Epsilon1 it advertises two scenes: one for the captures from Epsilon2 and one for the presentation. It includes one scene entry with the two captures from Epsilon2, and one entry with a single composed capture. It sends a comparable advertisement toward Epsilon2. Toward the computer endpoints that don't have the presentation floor it advertises a virtual scene containing the captures from Epsilon1 and Epsilon2. (Details TBD.) It also advertises another scene containing the presentation capture. Room Epsilon1 can map the two captures from the primary scene (from Epsilon2's cameras) and the presentation stream to its three displays. Room Epsilon2 can do likewise. The computers of users can simply select a single presentation capture in the received advertisement and present it. _________________________________ Alpha-MCU-Epsilon) CLUE conference between Alpha1 and Epsilon2 and the computers of the users in each. Room Alpha1 can map the two captures from the primary scene (from Epsilon2's cameras via the MCU) and the presentation stream to its three displays. >From the point of view of the MCU and Epsilon2 this is the same as Epsilon-MCU-Epsilon. _________________________________ Beta-MCU-Epsilon) CLUE conference between Beta1 and Epsilon2 and the computers of the users in each. The MCU presents a CLUE interface to the two rooms and the user's computers in Epsilon2. It also supports a BFCP interface for requesting the presentation floor. The MCU selects the preferred entry from the single scene advertised by each room, so it has three main captures from Beta1 and two main captures from Epsilon2. In addition, if the presentation floor has been requested via BFCP, then it selects the presentation capture advertised by that endpoint. Toward Beta1 it advertises one or two scenes. In the first it includes one scene entry with the two captures from Epsilon2, and one entry with a single composed capture. If there is a presentation not from Beta1, then in the second it includes one scene entry with the presentation. It sends a comparable advertisement toward Epsilon2. Toward the computer endpoints that don't have the presentation floor it advertises a virtual scene containing the captures from Beta1 and Epsilon2. (Details TBD.) To those without the floor it also advertises another scene containing the presentation capture. Room Beta1 can map the two captures from the primary scene (from Epsilon2's cameras) to two of its displays, and the presentation stream to its other display. Room Epsilon2 can map the two captures from the primary scene (from Beta1's cameras) and the presentation stream to its three displays. If the presentation is from Beta1, the spatial relationship it had to the other captures has been lost, so it may be mapped differently than Beta1 preferred. The computers of users can simply select a single presentation capture in the received advertisement and present it. _________________________________ Gamma-MCU-Epsilon) CLUE conference between Gamma1 and Epsilon2 and the computers of the users in Epsilon2. The MCU presents a CLUE interface to the two rooms and the user's computers in Epsilon2. It also supports a BFCP interface for requesting the presentation floor. The MCU selects the preferred entry from each scene advertised by each room, so it has three main captures from Gamma1 and two main captures from Epsilon2. In addition, if the presentation floor has been requested via BFCP, then it selects the presentation capture advertised by that endpoint. Toward Gamma1 it advertises two scenes. In the first it includes one scene entry with the two captures from Epsilon2, and one entry with a single composed capture. If there is a presentation not from Gamma1, then in the second it includes one scene entry with the presentation. Toward Epsilon2 it advertises two scenes. In the first it includes one scene entry with the three captures from Gamma1, and one entry with a single composed capture. If there is a presentation, then in the second it includes one scene entry with the presentation. Toward the computer endpoints that don't have the presentation floor it advertises a virtual scene containing the captures from Gamma1 and Epsilon2. (Details TBD.) It also advertises another scene containing the presentation capture. Room Gamma1 can map the two captures from the primary scene (from Epsilon2's cameras) to two of its displays. It can map the presentation stream either to its third display, or to the workstations, or both. When there is no presentation, Epsilon2 can map the three captures from the primary scene entry (from Gamma1's cameras) to its three displays. When there is a presentation, the controller for room Epsilon2 doesn't have enough displays to map all three captures from Gamma1's cameras and the presentation capture. If it knows the participants can see the presentation via their computers then it can map the other three captures to its displays. If not, then it will probably need to use one screen for the presentation, and select the composed entry for display on one of its other displays. The computers of users in Epsilon2 can simply select a single presentation capture in the received advertisement and present it. _________________________________ Multi-Epsilon-Switching-MCU) CLUE conference between Epsilon1,2,3 and the computers of the users in each. The MCU presents a CLUE interface to the rooms and the user's computers. It also supports a BFCP interface for requesting the presentation floor. The MCU selects the preferred entry from each scene advertised by each room, so it has two main captures from each room. In addition, if the presentation floor has been requested via BFCP, then it selects the presentation capture advertised by that endpoint. Toward each room and computer it advertises two scenes: one for the main captures and one for the presentation (if the presentation isn't coming from that room). In the main capture scene it includes one scene entry with all (four) captures from the other rooms. It includes another entry with two switched captures containing the captures from the room with the current speaker. It also includes an entry with a single capture containing a composition of the two cameras from the current speaker. The rooms don't have enough displays to handle the four-capture entry. So they select the two-switched-capture entry and map it to two of their displays. The presentation can be mapped to the other display. The computers of users can simply select a single presentation capture in the received advertisement and present it. (Or not, since its displayed in the room.) With a suitable UI, the users can select any or all of the other captures and display them locally. _________________________________ Multi-Epsilon-Passthru-MCU) CLUE conference between Epsilon1,2,3 and the computers of the users in each. The MCU presents a CLUE interface to the rooms and the user's computers. It also supports a BFCP interface for requesting the presentation floor. The MCU selects the preferred entry from each scene advertised by each room, so it has two main captures from each room. In addition, if the presentation floor has been requested via BFCP, then it selects the presentation capture advertised by that endpoint. Toward each room and computer it advertises several scenes - one for each scene it has received for some other endpoint, containing the captures it has selected from that scene. Each such scene will replicate the attributes from the received scene. Only one presentation scene is advertised - the one from the source that holds the floor. Each scene has only one entry. Each room and computer is responsible for selecting the advertised captures and mapping them to its display equipment. In this case, each room will be receiving four main captures and optionally a presentation capture. It will want to display them all somehow - many options are possible. If the room does not have the capability to compose captures, or doesn't have the bandwidth to receive so many captures, then it may produce a poor result. The computers of users can simply select a single presentation capture in the received advertisement and present it. (Or not, since its displayed in the room.) With a suitable UI, the users can select any or all of the other captures and display them locally. _________________________________ Multi-Epsilon-MultiFunction-MCU) This is a combination of Multi-Epsilon-Switched-MCU and Multi-Epsilon-Passthru-MCU. It advertises all the scenes advertised by each of those - one scene from each room plus one scene containing switched captures, plus one scene for the presentation capture. This is intended to allow the endpoints maximal flexibility. Each endpoint can act as it would in either of those other cases, depending upon which is most convenient or yields the best result. BUT, to do this correctly each endpoint must realize that the scene containing the switched captures is an alternative to those scenes containing unswitched main captures. There is currently nothing proposed that would facilitate that. More likely it would simply decide there are more captures to display. --------------010001090106050107060204-- From internet-drafts@ietf.org Fri May 25 13:54:14 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD0B221F87F7; Fri, 25 May 2012 13:54:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fP1PYPxVlYAa; Fri, 25 May 2012 13:54:14 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5711B21F87E5; Fri, 25 May 2012 13:54:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120525205414.17233.52875.idtracker@ietfa.amsl.com> Date: Fri, 25 May 2012 13:54:14 -0700 Cc: clue@ietf.org Subject: [clue] I-D Action: draft-ietf-clue-framework-05.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 25 May 2012 20:54:14 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the ControLling mUltiple streams for tEle= presence Working Group of the IETF. Title : Framework for Telepresence Multi-Streams Author(s) : Allyn Romanow Mark Duckworth Andrew Pepperell Brian Baldino Filename : draft-ietf-clue-framework-05.txt Pages : 36 Date : 2012-05-25 This memo offers a framework for a protocol that enables devices in a telepresence conference to interoperate by specifying the relationships between multiple media streams. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-clue-framework-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-clue-framework-05.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-clue-framework/ From eckelcu@cisco.com Fri May 25 13:59:37 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1020121F880B for ; Fri, 25 May 2012 13:59:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.479 X-Spam-Level: X-Spam-Status: No, score=-10.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YVpjzQaHXgcV for ; Fri, 25 May 2012 13:59:36 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 1E3C421F8804 for ; Fri, 25 May 2012 13:59:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=5938; q=dns/txt; s=iport; t=1337979576; x=1339189176; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=AM6/aLN7CFTzbY7ykfLZMU2lyaHWm24fPHhtDM64LZk=; b=RDfYOm8o2l0sLZZmYOmgjMqAkw9+VUqOZgOW7Dr56atJzDXXvO1rW51D Ic9aQT0rC4yvUjXodNL7DsrSWUaEGcIeexqiW+3lSdy9j7BgOz1XfBdv4 khlnrru52rEDEkK5xnbFvF6NQEZ8szQ6BPs+dUwA/7r8sAKX42pevEbDf A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAEnxv0+tJV2c/2dsb2JhbABEtRqBB4IVAQEBBBIBHQouHQQCAQgRBAEBCwYXAQYBRQkIAQEEARIIGodqAZh+n1iLASSEQmADiD+aZYFkgwA X-IronPort-AV: E=Sophos;i="4.75,658,1330905600"; d="scan'208";a="86828878" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-3.cisco.com with ESMTP; 25 May 2012 20:59:34 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id q4PKxXpp028819; Fri, 25 May 2012 20:59:34 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); Fri, 25 May 2012 13:59:33 -0700 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, 25 May 2012 13:59:33 -0700 Message-ID: In-Reply-To: <44C6B6B2D0CF424AA90B6055548D7A6102FD96A17C@CRPMBOXPRD01.polycom.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] capture attributes - content attribute Thread-Index: Ac04RnZOA9sBnQ6tSvaEcDiurur32QBsfufgAC/cqTA= References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC0782890E@xmb-sjc-221.amer.cisco.com> <44C6B6B2D0CF424AA90B6055548D7A6102FD96A17C@CRPMBOXPRD01.polycom.com> From: "Charles Eckel (eckelcu)" To: "Duckworth, Mark" , X-OriginalArrivalTime: 25 May 2012 20:59:33.0795 (UTC) FILETIME=[495F3730:01CD3AB9] Subject: Re: [clue] capture attributes - content attribute X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 25 May 2012 20:59:37 -0000 The IMTC best practice document for role based video streams (RBVS) has been shared via a liaison statement with the RAI areas. It is not a publically available document at this time. Publishing as a publically available document is a work item scheduled to be completed this calendar year. My recommendation would be to reuse the existing RFC 4796 content attribute. For interworking with existing implementations, use the values of "main" and "slides" to represent main video and content. This is consistent with IMTC's recommendations for RBVS. If/when there is a desire to extend the set of values beyond these two, either: - provide guidance on how to additional values already defined in RFC 4796 - define new values per extensibility outlined in RFC 4796, and provide guidance on how to use these values For now, it seems the restricted set containing only "main" and "slides" is sufficient, even if not ideal. Cheers, Charles > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Duckworth, Mark > Sent: Thursday, May 24, 2012 3:16 PM > To: clue@ietf.org > Subject: Re: [clue] capture attributes - content attribute >=20 > I think it would be good for CLUE to have easy interoperability with > existing devices that follow the IMTC document for Role Based Video > Streams. So it makes sense to me for CLUE to have one attribute with > only two specific values, that map directly to the content attribute > values of main and slides that are used for RBVS. I don't care too > much what we name we give to it, as long as somehow it is specified how > to map it to the RBVS usage. >=20 >=20 >=20 > For extensibility, if we add more possible values than just main and > slides, would we want to relate it to RBVS somehow? For example if > there is a "speaker" but no "main", would the speaker be treated as > "main"? Or if there is a "speaker" and "main", then the legacy RBVS > system should see the "main" one but not "speaker"? >=20 >=20 >=20 > Or would it be better for extensibility to have a separate attribute > name which can take on more new values? For example: >=20 > Attribute: content - possible values: {main, slides} >=20 > Attribute: clue-extensible-role - possible values: {speaker, sign > language, audience, ...} >=20 >=20 >=20 > A media capture could use both attributes, for example content=3Dmain, > clue-extensible-role=3Daudience. Would that work? Do you see a > significant difference between extending it this way, rather than > adding more possible values to the content attribute? >=20 >=20 >=20 > Adding more roles seems related to Ticket #8 also. People (including > me) have suggested using such additional role attributes to distinguish > between multiple capture scenes. >=20 >=20 >=20 > Mark >=20 >=20 >=20 >=20 >=20 > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Allyn Romanow (allyn) > Sent: Tuesday, May 22, 2012 2:13 PM > To: CLUE > Subject: [clue] capture attributes - content attribute >=20 >=20 >=20 > Folks, >=20 > Earlier we changed the capture attribute "purpose" with values > presentation and main to content attribute taken from RFC 4976 with > content types slides, main, speaker, >=20 >=20 >=20 > Initially, when this came up, I thought it was a simple change and it > had the appeal of using an existing RFC, so I wasn't opposed to it. > However, in working on a proof of concept implementation, this seemed > to have issues and I feel we should stay with purpose and main and > presentation, or at the most, change it to content with main and slides > as did the IMTC SIP Parity WG for Role Based Video Streams. >=20 >=20 >=20 > My primary reason for wanting to define only main and presentation (or > content attributes main and slides from the full list in RFC 4796) is > similar to the reasoning from the SIP Parity WG - that in a conference > It can easily create confusion and lack of non-interoperability - for > example one system may use main and another speaker when referring to > the same situation. This same view was actually expressed in the > Role Based Video Stream work in IMTC SIP Parity WG which decided to > support only main and slides. >=20 >=20 >=20 > Here is what is in the RBVS document on this topic (of course they > aren't using the attributes for audio, just video). >=20 >=20 >=20 > Unlike H.239 where there are only two channel roles, "live" and > "presentation", in SIP, there are more roles, and it is possible that > endpoints and MCUs will have to deal with the situation where all of > the participants in a call do not designate the same roles for their > channels. For example, one endpoint in a multipoint conference may use > the "speaker" and "slides" roles for its video channels, while another > may use "main" and "alt" for its video channels. Since there are no > mechanisms to enable MCUs and endpoints to interoperate in this type of > situation, all SIP-based endpoints conforming to the RBVS "Best > Practices" Profile MUST use the attributes as specified in this > section. [ i.e., main and slides] The handling of other 'content' > attribute values is considered out of scope. >=20 >=20 >=20 >=20 >=20 > Although I'm okay with using just slides and main from the content > attribute, I feel that purpose: presentation, main map better to audio > than do slides and main. >=20 >=20 >=20 > I noticed today during the CLUE WG meeting that people reverted to > speaking about purpose main and presentation instead of the new content > attribute categories.. which is just an anecdote suggesting that we > stick with what we first had. >=20 >=20 >=20 > Of course, I'm assuming that we add any values to purpose (or content) > as they arise. >=20 >=20 >=20 > Thoughts? From pkyzivat@alum.mit.edu Fri May 25 16:02:36 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2798F21F8823 for ; Fri, 25 May 2012 16:02:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.68 X-Spam-Level: X-Spam-Status: No, score=-2.68 tagged_above=-999 required=5 tests=[AWL=-0.081, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jl2Sl5LPiT3V for ; Fri, 25 May 2012 16:02:35 -0700 (PDT) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [76.96.59.228]) by ietfa.amsl.com (Postfix) with ESMTP id 1233421F8826 for ; Fri, 25 May 2012 16:02:33 -0700 (PDT) Received: from omta10.westchester.pa.mail.comcast.net ([76.96.62.28]) by qmta15.westchester.pa.mail.comcast.net with comcast id ENh21j00A0cZkys5FP2Zpn; Fri, 25 May 2012 23:02:33 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta10.westchester.pa.mail.comcast.net with comcast id EP2Z1j00P07duvL3WP2ZkR; Fri, 25 May 2012 23:02:33 +0000 Message-ID: <4FC00F89.4030808@alum.mit.edu> Date: Fri, 25 May 2012 19:02:33 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: clue@ietf.org References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC0782890E@xmb-sjc-221.amer.cisco.com> <44C6B6B2D0CF424AA90B6055548D7A6102FD96A17C@CRPMBOXPRD01.polycom.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] capture attributes - content attribute X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 25 May 2012 23:02:36 -0000 On 5/25/12 4:59 PM, Charles Eckel (eckelcu) wrote: > The IMTC best practice document for role based video streams (RBVS) has > been shared via a liaison statement with the RAI areas. It is not a > publically available document at this time. Publishing as a publically > available document is a work item scheduled to be completed this > calendar year. I don't understand what you mean about it being shared via a liaison statement. Does that mean its available to some IETF people in some way? What semantics does it ascribe to "main" and "slides"? If we adopt "slides" but use it more generally to denote a video stream that might contain a rendition of a presentation more general than slides, are we abusing it? Thanks, Paul > My recommendation would be to reuse the existing RFC 4796 content > attribute. > For interworking with existing implementations, use the values of "main" > and "slides" to represent main video and content. This is consistent > with IMTC's recommendations for RBVS. > If/when there is a desire to extend the set of values beyond these two, > either: > - provide guidance on how to additional values already defined in RFC > 4796 > - define new values per extensibility outlined in RFC 4796, and provide > guidance on how to use these values > > For now, it seems the restricted set containing only "main" and "slides" > is sufficient, even if not ideal. > > Cheers, > Charles > >> -----Original Message----- >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf > Of >> Duckworth, Mark >> Sent: Thursday, May 24, 2012 3:16 PM >> To: clue@ietf.org >> Subject: Re: [clue] capture attributes - content attribute >> >> I think it would be good for CLUE to have easy interoperability with >> existing devices that follow the IMTC document for Role Based Video >> Streams. So it makes sense to me for CLUE to have one attribute with >> only two specific values, that map directly to the content attribute >> values of main and slides that are used for RBVS. I don't care too >> much what we name we give to it, as long as somehow it is specified > how >> to map it to the RBVS usage. >> >> >> >> For extensibility, if we add more possible values than just main and >> slides, would we want to relate it to RBVS somehow? For example if >> there is a "speaker" but no "main", would the speaker be treated as >> "main"? Or if there is a "speaker" and "main", then the legacy RBVS >> system should see the "main" one but not "speaker"? >> >> >> >> Or would it be better for extensibility to have a separate attribute >> name which can take on more new values? For example: >> >> Attribute: content - possible values: {main, slides} >> >> Attribute: clue-extensible-role - possible values: {speaker, sign >> language, audience, ...} >> >> >> >> A media capture could use both attributes, for example content=main, >> clue-extensible-role=audience. Would that work? Do you see a >> significant difference between extending it this way, rather than >> adding more possible values to the content attribute? >> >> >> >> Adding more roles seems related to Ticket #8 also. People (including >> me) have suggested using such additional role attributes to > distinguish >> between multiple capture scenes. >> >> >> >> Mark >> >> >> >> >> >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf > Of >> Allyn Romanow (allyn) >> Sent: Tuesday, May 22, 2012 2:13 PM >> To: CLUE >> Subject: [clue] capture attributes - content attribute >> >> >> >> Folks, >> >> Earlier we changed the capture attribute "purpose" with values >> presentation and main to content attribute taken from RFC 4976 with >> content types slides, main, speaker, >> >> >> >> Initially, when this came up, I thought it was a simple change and it >> had the appeal of using an existing RFC, so I wasn't opposed to it. >> However, in working on a proof of concept implementation, this seemed >> to have issues and I feel we should stay with purpose and main and >> presentation, or at the most, change it to content with main and > slides >> as did the IMTC SIP Parity WG for Role Based Video Streams. >> >> >> >> My primary reason for wanting to define only main and presentation (or >> content attributes main and slides from the full list in RFC 4796) is >> similar to the reasoning from the SIP Parity WG - that in a conference >> It can easily create confusion and lack of non-interoperability - for >> example one system may use main and another speaker when referring to >> the same situation. This same view was actually expressed in the >> Role Based Video Stream work in IMTC SIP Parity WG which decided to >> support only main and slides. >> >> >> >> Here is what is in the RBVS document on this topic (of course they >> aren't using the attributes for audio, just video). >> >> >> >> Unlike H.239 where there are only two channel roles, "live" and >> "presentation", in SIP, there are more roles, and it is possible that >> endpoints and MCUs will have to deal with the situation where all of >> the participants in a call do not designate the same roles for their >> channels. For example, one endpoint in a multipoint conference may > use >> the "speaker" and "slides" roles for its video channels, while another >> may use "main" and "alt" for its video channels. Since there are no >> mechanisms to enable MCUs and endpoints to interoperate in this type > of >> situation, all SIP-based endpoints conforming to the RBVS "Best >> Practices" Profile MUST use the attributes as specified in this >> section. [ i.e., main and slides] The handling of other 'content' >> attribute values is considered out of scope. >> >> >> >> >> >> Although I'm okay with using just slides and main from the content >> attribute, I feel that purpose: presentation, main map better to audio >> than do slides and main. >> >> >> >> I noticed today during the CLUE WG meeting that people reverted to >> speaking about purpose main and presentation instead of the new > content >> attribute categories.. which is just an anecdote suggesting that we >> stick with what we first had. >> >> >> >> Of course, I'm assuming that we add any values to purpose (or content) >> as they arise. >> >> >> >> Thoughts? > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From pkyzivat@alum.mit.edu Fri May 25 16:17:16 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C72321F884E for ; Fri, 25 May 2012 16:17:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.675 X-Spam-Level: X-Spam-Status: No, score=-2.675 tagged_above=-999 required=5 tests=[AWL=-0.076, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OJBvwQQ1F6NJ for ; Fri, 25 May 2012 16:17:16 -0700 (PDT) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [76.96.62.56]) by ietfa.amsl.com (Postfix) with ESMTP id D828A21F882C for ; Fri, 25 May 2012 16:17:15 -0700 (PDT) Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by qmta06.westchester.pa.mail.comcast.net with comcast id EP9j1j0010QuhwU56PHFAV; Fri, 25 May 2012 23:17:15 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta02.westchester.pa.mail.comcast.net with comcast id EPHE1j00y07duvL3NPHFJi; Fri, 25 May 2012 23:17:15 +0000 Message-ID: <4FC012FA.8060103@alum.mit.edu> Date: Fri, 25 May 2012 19:17:14 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: CLUE References: <20120525205414.17233.52875.idtracker@ietfa.amsl.com> In-Reply-To: <20120525205414.17233.52875.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] I-D Action: draft-ietf-clue-framework-05.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 25 May 2012 23:17:16 -0000 I have a question about the site switching definition in the new version: If the sites provide differing numbers of captures, how does that affect site switching? Presumably the entry should have enough captures to cover all those provided by any one site. What should happen when switching to a site that provides fewer captures? Should transmission stop for the unneeded captures? Or should placeholder content be sent? Or should captures from some other site (e.g. from the previously selected site) be sent? Thanks, Paul From mary.ietf.barnes@gmail.com Fri May 25 16:18:08 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DB5021F884D for ; Fri, 25 May 2012 16:18:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.773 X-Spam-Level: X-Spam-Status: No, score=-102.773 tagged_above=-999 required=5 tests=[AWL=-0.841, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4MtJrUmPwChb for ; Fri, 25 May 2012 16:18:07 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id E0AF121F882C for ; Fri, 25 May 2012 16:18:06 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so1200984vbb.31 for ; Fri, 25 May 2012 16:18:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ooJoBhbSProTxsmmJv2P7114kAjtFlONwpwHP306lHE=; b=U0EzOYVq7tFu+OIubT7UtHMGNqFr/w9iy1XLJ0HOvQrKenTqqXX2tUsrA+0Lx6m7JG j2+MKnWnpLc7FFzh80Gk0tc983C39pFvnzsYujqNjQJNvkPKAGh3Bd6yx1Gkqe49f+rj vAZghrEG6EnboLRhKmjRvrvqPOe+QOXuQmGPYB63aliNwMDqpznoHKNgomh8KqR6pvFw A8cgx0vxiKZG8yl/jm3WOoQaigRXsKfaKAmkwXLohOK0GuFeUUl9QL/UCf1e6l/2pZ1Q mPaEjvj47nCxO/y06cRLZrNbV6RDdPTBUFO8tR+66HibRE6qKZB1Tsu775zgybhN9Tjf 58RA== MIME-Version: 1.0 Received: by 10.52.28.71 with SMTP id z7mr550675vdg.105.1337987884591; Fri, 25 May 2012 16:18:04 -0700 (PDT) Received: by 10.52.22.143 with HTTP; Fri, 25 May 2012 16:18:04 -0700 (PDT) In-Reply-To: <4FC00F89.4030808@alum.mit.edu> References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC0782890E@xmb-sjc-221.amer.cisco.com> <44C6B6B2D0CF424AA90B6055548D7A6102FD96A17C@CRPMBOXPRD01.polycom.com> <4FC00F89.4030808@alum.mit.edu> Date: Fri, 25 May 2012 18:18:04 -0500 Message-ID: From: Mary Barnes To: Paul Kyzivat Content-Type: multipart/alternative; boundary=20cf3078119e93293f04c0e49478 Cc: rai-ads@tools.ietf.org, clue@ietf.org Subject: Re: [clue] capture attributes - content attribute X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 25 May 2012 23:18:08 -0000 --20cf3078119e93293f04c0e49478 Content-Type: text/plain; charset=ISO-8859-1 Any official liaison statements should end up being posted here: https://datatracker.ietf.org/liaison/ There was an LS sent to the SIPCORE mailing list: http://www.ietf.org/mail-archive/web/sipcore/current/msg04522.html But, was about the Security document, which was attached to the email. Charles, can you please point us to the LS with regards to the Role Based Video document. I know it was mentioned in one of the chair charts in a DISPATCH session, but we consider things like that as FYIs as opposed to an LS. The LS on the security document should have been forwarded by the chairs to statements@ietf.org so it could be posted on the liaison webpage. I think the secretariat forwards any LS that it they receive to the appropriate WG chairs, ADS, etc. We also don't seem to have an IETF liaison to IMTC - the need for such is likely something that needs to be discussed elsewhere (i.e., on the RAI list or even on the IAB list). Mary. On Fri, May 25, 2012 at 6:02 PM, Paul Kyzivat wrote: > > > On 5/25/12 4:59 PM, Charles Eckel (eckelcu) wrote: > >> The IMTC best practice document for role based video streams (RBVS) has >> been shared via a liaison statement with the RAI areas. It is not a >> publically available document at this time. Publishing as a publically >> available document is a work item scheduled to be completed this >> calendar year. >> > > I don't understand what you mean about it being shared via a liaison > statement. Does that mean its available to some IETF people in some way? > > What semantics does it ascribe to "main" and "slides"? > If we adopt "slides" but use it more generally to denote a video stream > that might contain a rendition of a presentation more general than slides, > are we abusing it? > > Thanks, > Paul > > > My recommendation would be to reuse the existing RFC 4796 content >> attribute. >> For interworking with existing implementations, use the values of "main" >> and "slides" to represent main video and content. This is consistent >> with IMTC's recommendations for RBVS. >> If/when there is a desire to extend the set of values beyond these two, >> either: >> - provide guidance on how to additional values already defined in RFC >> 4796 >> - define new values per extensibility outlined in RFC 4796, and provide >> guidance on how to use these values >> >> For now, it seems the restricted set containing only "main" and "slides" >> is sufficient, even if not ideal. >> >> Cheers, >> Charles >> >> -----Original Message----- >>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf >>> >> Of >> >>> Duckworth, Mark >>> Sent: Thursday, May 24, 2012 3:16 PM >>> To: clue@ietf.org >>> Subject: Re: [clue] capture attributes - content attribute >>> >>> I think it would be good for CLUE to have easy interoperability with >>> existing devices that follow the IMTC document for Role Based Video >>> Streams. So it makes sense to me for CLUE to have one attribute with >>> only two specific values, that map directly to the content attribute >>> values of main and slides that are used for RBVS. I don't care too >>> much what we name we give to it, as long as somehow it is specified >>> >> how >> >>> to map it to the RBVS usage. >>> >>> >>> >>> For extensibility, if we add more possible values than just main and >>> slides, would we want to relate it to RBVS somehow? For example if >>> there is a "speaker" but no "main", would the speaker be treated as >>> "main"? Or if there is a "speaker" and "main", then the legacy RBVS >>> system should see the "main" one but not "speaker"? >>> >>> >>> >>> Or would it be better for extensibility to have a separate attribute >>> name which can take on more new values? For example: >>> >>> Attribute: content - possible values: {main, slides} >>> >>> Attribute: clue-extensible-role - possible values: {speaker, sign >>> language, audience, ...} >>> >>> >>> >>> A media capture could use both attributes, for example content=main, >>> clue-extensible-role=audience. Would that work? Do you see a >>> significant difference between extending it this way, rather than >>> adding more possible values to the content attribute? >>> >>> >>> >>> Adding more roles seems related to Ticket #8 also. People (including >>> me) have suggested using such additional role attributes to >>> >> distinguish >> >>> between multiple capture scenes. >>> >>> >>> >>> Mark >>> >>> >>> >>> >>> >>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf >>> >> Of >> >>> Allyn Romanow (allyn) >>> Sent: Tuesday, May 22, 2012 2:13 PM >>> To: CLUE >>> Subject: [clue] capture attributes - content attribute >>> >>> >>> >>> Folks, >>> >>> Earlier we changed the capture attribute "purpose" with values >>> presentation and main to content attribute taken from RFC 4976 with >>> content types slides, main, speaker, >>> >>> >>> >>> Initially, when this came up, I thought it was a simple change and it >>> had the appeal of using an existing RFC, so I wasn't opposed to it. >>> However, in working on a proof of concept implementation, this seemed >>> to have issues and I feel we should stay with purpose and main and >>> presentation, or at the most, change it to content with main and >>> >> slides >> >>> as did the IMTC SIP Parity WG for Role Based Video Streams. >>> >>> >>> >>> My primary reason for wanting to define only main and presentation (or >>> content attributes main and slides from the full list in RFC 4796) is >>> similar to the reasoning from the SIP Parity WG - that in a conference >>> It can easily create confusion and lack of non-interoperability - for >>> example one system may use main and another speaker when referring to >>> the same situation. This same view was actually expressed in the >>> Role Based Video Stream work in IMTC SIP Parity WG which decided to >>> support only main and slides. >>> >>> >>> >>> Here is what is in the RBVS document on this topic (of course they >>> aren't using the attributes for audio, just video). >>> >>> >>> >>> Unlike H.239 where there are only two channel roles, "live" and >>> "presentation", in SIP, there are more roles, and it is possible that >>> endpoints and MCUs will have to deal with the situation where all of >>> the participants in a call do not designate the same roles for their >>> channels. For example, one endpoint in a multipoint conference may >>> >> use >> >>> the "speaker" and "slides" roles for its video channels, while another >>> may use "main" and "alt" for its video channels. Since there are no >>> mechanisms to enable MCUs and endpoints to interoperate in this type >>> >> of >> >>> situation, all SIP-based endpoints conforming to the RBVS "Best >>> Practices" Profile MUST use the attributes as specified in this >>> section. [ i.e., main and slides] The handling of other 'content' >>> attribute values is considered out of scope. >>> >>> >>> >>> >>> >>> Although I'm okay with using just slides and main from the content >>> attribute, I feel that purpose: presentation, main map better to audio >>> than do slides and main. >>> >>> >>> >>> I noticed today during the CLUE WG meeting that people reverted to >>> speaking about purpose main and presentation instead of the new >>> >> content >> >>> attribute categories.. which is just an anecdote suggesting that we >>> stick with what we first had. >>> >>> >>> >>> Of course, I'm assuming that we add any values to purpose (or content) >>> as they arise. >>> >>> >>> >>> Thoughts? >>> >> >> ______________________________**_________________ >> 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 > --20cf3078119e93293f04c0e49478 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Any official liaison statements should end up being posted here:

There was an LS sent to the SIPCORE mai= ling list:
But, was about the Security document, which was attached to = the email. Charles, can you please point us to the LS with regards to the R= ole Based Video document. =A0I know it was mentioned in one of the chair ch= arts in a DISPATCH session, but we consider things like that as FYIs as opp= osed to an LS.=A0

The LS on the security document should have been forwar= ded by the chairs to statements@ietf= .org so it could be posted on the liaison webpage. =A0I think the secre= tariat forwards any LS that it they receive to the appropriate WG chairs, A= DS, etc.=A0

We also don't seem to have an IETF liaison to IMTC = - the need for such is likely something that needs to be discussed elsewher= e (i.e., on the RAI list or even on the IAB list). =A0

Mary. =A0

On Fri, May 25, 201= 2 at 6:02 PM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote= :


On 5/25/12 4:59 PM, Charles Eckel (eckelcu) wrote:
The IMTC best practice document for role based video streams (RBVS) has
been shared via a liaison statement with the RAI areas. It is not a
publically available document at this time. Publishing as a publically
available document is a work item scheduled to be completed this
calendar year.

I don't understand what you mean about it being shared via a liaison st= atement. Does that mean its available to some IETF people in some way?

What semantics does it ascribe to "main" and "slides"?<= br> If we adopt "slides" but use it more generally to denote a video = stream that might contain a rendition of a presentation more general than s= lides, are we abusing it?

=A0 =A0 =A0 =A0Thanks,
=A0 =A0 =A0 =A0Paul


My recommendation would be to reuse the existing RFC 4796 content
attribute.
For interworking with existing implementations, use the values of "mai= n"
and "slides" to represent main video and content. This is consist= ent
with IMTC's recommendations for RBVS.
If/when there is a desire to extend the set of values beyond these two,
either:
- provide guidance on how to additional values already defined in RFC
4796
- define new values per extensibility outlined in RFC 4796, and provide
guidance on how to use these values

For now, it seems the restricted set containing only "main" and &= quot;slides"
is sufficient, even if not ideal.

Cheers,
Charles

-----Original Message-----
From: clue-bounc= es@ietf.org [mailto:clue-bounces@ietf.org] On Behalf
Of
Duckworth, Mark
Sent: Thursday, May 24, 2012 3:16 PM
To: clue@ietf.org Subject: Re: [clue] capture attributes - content attribute

I think it would be good for CLUE to have easy interoperability with
existing devices that follow the IMTC document for Role Based Video
Streams. =A0So it makes sense to me for CLUE to have one attribute with
only two specific values, that map directly to the content attribute
values of main and slides that are used for RBVS. =A0I don't care too much what we name we give to it, as long as somehow it is specified
how
to map it to the RBVS usage.



For extensibility, if we add more possible values than just main and
slides, would we want to relate it to RBVS somehow? =A0For example if
there is a "speaker" but no "main", would the speaker b= e treated as
"main"? =A0Or if there is a "speaker" and "main&qu= ot;, then the legacy RBVS
system should see the "main" one but not "speaker"?



Or would it be better for extensibility to have a separate attribute
name which can take on more new values? =A0For example:

=A0 Attribute: content - possible values: {main, slides}

=A0Attribute: clue-extensible-role - possible values: {speaker, sign
language, audience, ...}



A media capture could use both attributes, for example content=3Dmain,
clue-extensible-role=3Daudience. =A0Would that work? =A0Do you see a
significant difference between extending it this way, rather than
adding more possible values to the content attribute?



Adding more roles seems related to Ticket #8 also. =A0People (including
me) have suggested using such additional role attributes to
distinguish
between multiple capture scenes.



Mark





From: clue-bounc= es@ietf.org [mailto:clue-bounces@ietf.org] On Behalf
Of
Allyn Romanow (allyn)
Sent: Tuesday, May 22, 2012 2:13 PM
To: CLUE
Subject: [clue] capture attributes - content attribute



Folks,

Earlier we changed =A0the capture attribute "purpose" with values=
presentation and main to content attribute taken from RFC 4976 with
content types slides, main, speaker,



Initially, when this came up, =A0I thought it was a simple change and it had the appeal of using an existing RFC, so I wasn't opposed to it.
However, in working on a proof of concept implementation, this seemed
to have issues and =A0I feel we should stay with purpose and main and
presentation, or at the most, change it to content with main and
slides
as did the IMTC SIP Parity WG for Role Based Video Streams.



My primary reason for wanting to define only main and presentation (or
content attributes main and slides from the full list in RFC 4796) is
similar to the reasoning from the SIP Parity WG - that in a conference
It can easily create =A0confusion and lack of non-interoperability - for example one system may use main and another speaker when referring to
the same situation. =A0 =A0This same view was actually expressed in the
Role Based Video Stream work in IMTC SIP Parity WG which decided =A0to
support only main and slides.



Here is what is in the RBVS document on this topic (of course they
aren't using the attributes for audio, just video).



Unlike H.239 where there are only two channel roles, "live" and "presentation", in SIP, there are more roles, and it is possible = that
endpoints and MCUs will have to deal with the situation where all of
the participants in a call do not designate the same roles for their
channels. =A0For example, one endpoint in a multipoint conference may
use
the "speaker" and "slides" roles for its video channels= , while another
may use "main" and "alt" for its video channels. =A0 Si= nce there are no
mechanisms to enable MCUs and endpoints to interoperate in this type
of
situation, all SIP-based endpoints conforming to the RBVS "Best
Practices" Profile MUST use the attributes as specified in this
section. [ i.e., main and slides] The handling of other 'content' attribute values is considered out of scope.





Although I'm okay with using just slides and main from the content
attribute, I feel that purpose: presentation, main map better to audio
than do slides and main.



I noticed today during the CLUE WG meeting that people reverted to
speaking about purpose main and presentation instead of the new
content
attribute categories.. which is just an anecdote suggesting that we
stick with what we first had.



Of course, I'm assuming that we add any values to purpose (or content)<= br> as they arise.



Thoughts?

_______________________________________________
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

--20cf3078119e93293f04c0e49478-- From Mark.Duckworth@polycom.com Fri May 25 19:42:47 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C801121F8844 for ; Fri, 25 May 2012 19:42:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UWbfUkf0ZzsE for ; Fri, 25 May 2012 19:42:47 -0700 (PDT) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 658BD21F8842 for ; Fri, 25 May 2012 19:42:46 -0700 (PDT) Received: from Crpmboxprd01.polycom.com ([fe80::ad68:5a0:c919:66b6]) by crpehubprd02.polycom.com ([fe80::5efe:10.236.0.154%12]) with mapi; Fri, 25 May 2012 19:42:42 -0700 From: "Duckworth, Mark" To: Paul Kyzivat , CLUE Date: Fri, 25 May 2012 19:42:40 -0700 Thread-Topic: [clue] I-D Action: draft-ietf-clue-framework-05.txt Thread-Index: Ac06zIsFwnjyckqxRZSX7fNSiD7tlAAHEvQQ Message-ID: <44C6B6B2D0CF424AA90B6055548D7A6102FD96A507@CRPMBOXPRD01.polycom.com> References: <20120525205414.17233.52875.idtracker@ietfa.amsl.com> <4FC012FA.8060103@alum.mit.edu> In-Reply-To: <4FC012FA.8060103@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [clue] I-D Action: draft-ietf-clue-framework-05.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 May 2012 02:42:47 -0000 Hi Paul, The text describing the switching policies came from the use case document,= so there really isn't anything new here. IMO, the media provider has some leeway in deciding how to handle cases lik= e you mention, and still be able to call it site switching. Mark > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Paul Kyzivat > Sent: Friday, May 25, 2012 7:17 PM > To: CLUE > Subject: Re: [clue] I-D Action: draft-ietf-clue-framework-05.txt >=20 > I have a question about the site switching definition in the new version: >=20 > If the sites provide differing numbers of captures, how does that affect = site > switching? Presumably the entry should have enough captures to cover all > those provided by any one site. What should happen when switching to a > site that provides fewer captures? Should transmission stop for the > unneeded captures? Or should placeholder content be sent? > Or should captures from some other site (e.g. from the previously selecte= d > site) be sent? >=20 > Thanks, > Paul >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From Mark.Duckworth@polycom.com Sat May 26 05:27:04 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8C5B21F8589 for ; Sat, 26 May 2012 05:27:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pfux088-WtKW for ; Sat, 26 May 2012 05:27:04 -0700 (PDT) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 7933221F8585 for ; Sat, 26 May 2012 05:27:04 -0700 (PDT) Received: from Crpmboxprd01.polycom.com ([fe80::ad68:5a0:c919:66b6]) by crpehubprd02.polycom.com ([fe80::5efe:10.236.0.154%12]) with mapi; Sat, 26 May 2012 05:27:03 -0700 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Sat, 26 May 2012 05:27:02 -0700 Thread-Topic: scene description should be optional Thread-Index: Ac07OonW8LsRXvX/S1WT/1SLsYKnbA== Message-ID: <44C6B6B2D0CF424AA90B6055548D7A6102FD96A516@CRPMBOXPRD01.polycom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_44C6B6B2D0CF424AA90B6055548D7A6102FD96A516CRPMBOXPRD01p_" MIME-Version: 1.0 Subject: [clue] scene description should be optional X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 May 2012 12:27:05 -0000 --_000_44C6B6B2D0CF424AA90B6055548D7A6102FD96A516CRPMBOXPRD01p_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The framework-05 version has the new scene description attribute, but the d= ocument should say it is an optional attribute. I can add that to the next= version. Thanks Allyn for pointing this out. Mark --_000_44C6B6B2D0CF424AA90B6055548D7A6102FD96A516CRPMBOXPRD01p_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The framework-05= version has the new scene description attribute, but the document should s= ay it is an optional attribute.  I can add that to the next version.&n= bsp; Thanks Allyn for pointing this out.

 

Mark

= = --_000_44C6B6B2D0CF424AA90B6055548D7A6102FD96A516CRPMBOXPRD01p_-- From Christian.Groves@nteczone.com Mon May 28 19:58:06 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F16CF21F8770 for ; Mon, 28 May 2012 19:58:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q8d8j0y+T62H for ; Mon, 28 May 2012 19:58:05 -0700 (PDT) Received: from ipmail06.adl6.internode.on.net (ipmail06.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:6]) by ietfa.amsl.com (Postfix) with ESMTP id 0BBD121F85CC for ; Mon, 28 May 2012 19:58:04 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBAFk6xE920dYF/2dsb2JhbAANN4Uws0oBAQEEAQEBIBUbFQYEBhEjAgIFFgsCAgkDAgECARUwEwYCAQEFiA2ldJIYgSSGcIJvghuCBIESA6d6 Received: from ppp118-209-214-5.lns20.mel6.internode.on.net (HELO [127.0.0.1]) ([118.209.214.5]) by ipmail06.adl6.internode.on.net with ESMTP; 29 May 2012 12:28:03 +0930 Message-ID: <4FC43B38.1030703@nteczone.com> Date: Tue, 29 May 2012 12:58:00 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: clue@ietf.org References: <20120525205414.17233.52875.idtracker@ietfa.amsl.com> In-Reply-To: <20120525205414.17233.52875.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [clue] Language Re: I-D Action: draft-ietf-clue-framework-05.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 29 May 2012 02:58:06 -0000 Hello, With regards to the new description attribute and description language attribute in section 6.2.1 it appears that the intention is that only one language is supported. Would it make sense to allow these attributes to support the sending of multiple languages? i.e. a description could contain the name of a capture scene in Chinese as well as an English equivalent? Otherwise there would probably have to be some negotiation of a general "language" attribute so that an endpoint could send the correct language to the remote end point. Regards, Christian On 26/05/2012 6:54 AM, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the ControLling mUltiple streams for tElepresence Working Group of the IETF. > > Title : Framework for Telepresence Multi-Streams > Author(s) : Allyn Romanow > Mark Duckworth > Andrew Pepperell > Brian Baldino > Filename : draft-ietf-clue-framework-05.txt > Pages : 36 > Date : 2012-05-25 > > This memo offers a framework for a protocol that enables devices in a > telepresence conference to interoperate by specifying the > relationships between multiple media streams. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-clue-framework-05.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-clue-framework-05.txt > > The IETF datatracker page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-ietf-clue-framework/ > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From Christian.Groves@nteczone.com Mon May 28 20:23:46 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1778121F87C8 for ; Mon, 28 May 2012 20:23:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rVlXsxv58aqi for ; Mon, 28 May 2012 20:23:45 -0700 (PDT) Received: from ipmail06.adl6.internode.on.net (ipmail06.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:6]) by ietfa.amsl.com (Postfix) with ESMTP id 3703D21F8723 for ; Mon, 28 May 2012 20:23:44 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBAENAxE920dYF/2dsb2JhbAANN4Uws0oBAQEEAQEBIBUbFQYEBhEjAgIFFgsCAgkDAgECARUwEwYCAQEFiA2ldJIagSSJX4IbggSBEgOneg Received: from ppp118-209-214-5.lns20.mel6.internode.on.net (HELO [127.0.0.1]) ([118.209.214.5]) by ipmail06.adl6.internode.on.net with ESMTP; 29 May 2012 12:53:43 +0930 Message-ID: <4FC4413D.8030907@nteczone.com> Date: Tue, 29 May 2012 13:23:41 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: clue@ietf.org References: <20120525205414.17233.52875.idtracker@ietfa.amsl.com> In-Reply-To: <20120525205414.17233.52875.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [clue] Comments on Capture Scene attributes Re: I-D Action: draft-ietf-clue-framework-05.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 29 May 2012 03:23:46 -0000 Hello, 1. Section 6.2.1: The scale attribute starts off by saying "An optional attribute". Perhaps we should also use similar terminology for the description, description language and scene-switch policy attributes to make it clear if an attribute is mandatory or optional. 2. Section 6.2.1 Description Language: Perhaps we need some text to discuss the relationship with the description attribute? i.e. the Description Language attribute MUST be sent if the Description attribute is sent. 3. Section 6.2.1 Description Language: The reference to the IANA registry has several types: language, extlang, script, region. Which types will CLUE use? e.g. Hebrew is both a language "He" and a script "Hebr". 4. Section 6.2.2 it says "In the provider's advertisement, this attribute can have multiple values, which means the provider supports each of the indicated policies. The consumer, when it requests media captures from this capture scene entry, should also include this attribute but with only the single value..." Does the consumer behaviour need to be conditional? i.e. "If the consumer receives a scene-switch-policy attribute it should include this attribute with a single value when it requests media captures from this capture scene entry." Regards, Christian On 26/05/2012 6:54 AM, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the ControLling mUltiple streams for tElepresence Working Group of the IETF. > > Title : Framework for Telepresence Multi-Streams > Author(s) : Allyn Romanow > Mark Duckworth > Andrew Pepperell > Brian Baldino > Filename : draft-ietf-clue-framework-05.txt > Pages : 36 > Date : 2012-05-25 > > This memo offers a framework for a protocol that enables devices in a > telepresence conference to interoperate by specifying the > relationships between multiple media streams. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-clue-framework-05.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-clue-framework-05.txt > > The IETF datatracker page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-ietf-clue-framework/ > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From Even.roni@huawei.com Mon May 28 22:00:34 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 085D321F87CF for ; Mon, 28 May 2012 22:00:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vapBUOv7fMeS for ; Mon, 28 May 2012 22:00:33 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 1E35621F8715 for ; Mon, 28 May 2012 22:00:33 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AGI87978; Tue, 29 May 2012 01:00:32 -0400 (EDT) Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 28 May 2012 21:57:34 -0700 Received: from SZXEML419-HUB.china.huawei.com (10.82.67.158) by dfweml405-hub.china.huawei.com (10.193.5.102) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 28 May 2012 21:57:33 -0700 Received: from SZXEML536-MBX.china.huawei.com ([10.82.67.115]) by szxeml419-hub.china.huawei.com ([10.82.67.158]) with mapi id 14.01.0323.003; Tue, 29 May 2012 12:57:28 +0800 From: Roni even To: Christian Groves , "clue@ietf.org" Thread-Topic: [clue] Language Re: I-D Action: draft-ietf-clue-framework-05.txt Thread-Index: AQHNPUbnXquD+PKes0y1yWM8Hl/A3ZbgMzQo Date: Tue, 29 May 2012 04:57:27 +0000 Message-ID: References: <20120525205414.17233.52875.idtracker@ietfa.amsl.com>, <4FC43B38.1030703@nteczone.com> In-Reply-To: <4FC43B38.1030703@nteczone.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.24.1.45] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [clue] Language Re: I-D Action: draft-ietf-clue-framework-05.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 29 May 2012 05:00:34 -0000 Hi Christian, This is a good point, I also think that we should allow this functionality.= This allows the renderer to display one or multiple descriptions Roni ________________________________________ From: clue-bounces@ietf.org [clue-bounces@ietf.org] on behalf of Christian = Groves [Christian.Groves@nteczone.com] Sent: Tuesday, May 29, 2012 5:58 To: clue@ietf.org Subject: [clue] Language Re: I-D Action: draft-ietf-clue-framework-05.txt Hello, With regards to the new description attribute and description language attribute in section 6.2.1 it appears that the intention is that only one language is supported. Would it make sense to allow these attributes to support the sending of multiple languages? i.e. a description could contain the name of a capture scene in Chinese as well as an English equivalent? Otherwise there would probably have to be some negotiation of a general "language" attribute so that an endpoint could send the correct language to the remote end point. Regards, Christian On 26/05/2012 6:54 AM, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. This draft is a work item of the ControLling mUltiple streams for tE= lepresence Working Group of the IETF. > > Title : Framework for Telepresence Multi-Streams > Author(s) : Allyn Romanow > Mark Duckworth > Andrew Pepperell > Brian Baldino > Filename : draft-ietf-clue-framework-05.txt > Pages : 36 > Date : 2012-05-25 > > This memo offers a framework for a protocol that enables devices in a > telepresence conference to interoperate by specifying the > relationships between multiple media streams. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-clue-framework-05.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-clue-framework-05.txt > > The IETF datatracker page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-ietf-clue-framework/ > > _______________________________________________ > 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= From magnus.westerlund@ericsson.com Tue May 29 06:54:33 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF6A621F87C9 for ; Tue, 29 May 2012 06:54:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.193 X-Spam-Level: X-Spam-Status: No, score=-106.193 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SEs1HptrCs0U for ; Tue, 29 May 2012 06:54:33 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id F253021F87C7 for ; Tue, 29 May 2012 06:54:32 -0700 (PDT) X-AuditID: c1b4fb30-b7f606d0000002be-fd-4fc4d517bbc4 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 52.89.00702.715D4CF4; Tue, 29 May 2012 15:54:31 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.264.0; Tue, 29 May 2012 15:54:30 +0200 Message-ID: <4FC4D516.2090501@ericsson.com> Date: Tue, 29 May 2012 15:54:30 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: clue@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphluLIzCtJLcpLzFFi42KZGfG3Vlf86hF/g9tnlS32n7rM7MDosWTJ T6YAxigum5TUnMyy1CJ9uwSujMZTe1kLjnNUrJsr2sD4n62LkZNDQsBEYsqbNewQtpjEhXvr geJcHEICpxgl+l60QDnLGSUuHXnPAlLFK6AtsaXrHiOIzSKgKnFy7gsmEJtNwELi5o9GsKmi AsESL/ZcYYWoF5Q4OfMJUC8HhwiQ/fKKIEhYWCBJ4uTlFewgYSGBAInucwEgYU6BQIl12y8y QdwjKXHw3zWw25gF9CSmXG1hhLDlJZq3zmYGsYWArmlo6mCdwCg4C8myWUhaZiFpWcDIvIpR ODcxMye93FwvtSgzubg4P0+vOHUTIzAkD275bbCDcdN9sUOM0hwsSuK8eqr7/YUE0hNLUrNT UwtSi+KLSnNSiw8xMnFwSjUwJrm2ndiWLeGw1Lug+6pntP3y3ZxlIYoM6Yf+f45py/e5Uvn1 xvzN7ucEb0sEnOXxN+yW/vRd/JO7MXPsbql12yXPu1k9t7ih1NWrE/D9+TF9jStsnL0+XHH7 Wcw2pN+K3vTfiOcUx6/r+96dVTmpZ1YnnnhI6FC52xnbJ1NniUhZnfw2adp2JZbijERDLeai 4kQAPNJhKhcCAAA= Subject: Re: [clue] A chair's response to: My view of CLUE status and topics for Interim meeting X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 29 May 2012 13:54:34 -0000 On 2012-05-22 20:39, Mary Barnes wrote: > 4) RTP: Usage and mapping CLUE media captures [Jonathan and Roni are > working in this area. Roni has already indicated to the chairs that he > will update his draft. In addition, Magnus has requested agenda time > to discuss these additional points: > - Security > - Congestion Control > - Distribution of complexity > - Transport implications > - Handling of identities] I want to clarify that my agenda topic was for discussing RTP topologies and session structures and what properties you get around the above 5 topics depending on the different choices. 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 marshall.eubanks@gmail.com Tue May 29 06:57:24 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 302EE21F8741 for ; Tue, 29 May 2012 06:57:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.564 X-Spam-Level: X-Spam-Status: No, score=-103.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MMXaS-fBHwrA for ; Tue, 29 May 2012 06:57:23 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id E34F921F87C3 for ; Tue, 29 May 2012 06:57:22 -0700 (PDT) Received: by lagv3 with SMTP id v3so2951147lag.31 for ; Tue, 29 May 2012 06:57:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=k8fM/FXMhKKUVDARKtc6lvSUu30ZRDiJ5mnXI5YOKUc=; b=SZApLsZOxeZ+H3xohvFKp3hoppDWAACpPcZUgUY7BP03Fwx+6EkU74W0/OxNL8E/OO C+xtY72Oq+0epcd+nUNxD7tWvKaP3OnKQfoukUXvCYv8Yd2i9qrb7ygSe8k9/tXUvbyg s1yaU1KtIBoC6Qalh10uKwKoVQpdE+ty2pkHGv4HolMbelGpn7iCz4jpFvB7Kfcvl1OB 7fhGuhz3qIa3ybcVx6HNPuoQQsLi4eXMY/aUwZMCK8iW3TkWiRvFOw32WIxN+IMMj0Go FTgxeaGKtX5T+TW3uJoFc64jQGyt1Grw8GfXqDzqCGPXMMV5ebQaa0WBm3Zf/J/sBjbh 23jg== MIME-Version: 1.0 Received: by 10.152.104.77 with SMTP id gc13mr12299240lab.31.1338299841828; Tue, 29 May 2012 06:57:21 -0700 (PDT) Received: by 10.112.132.65 with HTTP; Tue, 29 May 2012 06:57:21 -0700 (PDT) Date: Tue, 29 May 2012 09:57:21 -0400 Message-ID: From: Marshall Eubanks To: clue Content-Type: text/plain; charset=ISO-8859-1 Subject: [clue] Phone call today? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 29 May 2012 13:57:24 -0000 It's on my schedule, but I don't see a discussion of it on list. Marshall From mary.ietf.barnes@gmail.com Tue May 29 09:32:19 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37D0921F8712 for ; Tue, 29 May 2012 09:32:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.575 X-Spam-Level: X-Spam-Status: No, score=-103.575 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Anub3WE2KpOT for ; Tue, 29 May 2012 09:32:18 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9E0AD21F870F for ; Tue, 29 May 2012 09:32:18 -0700 (PDT) Received: by vcqp1 with SMTP id p1so2607563vcq.31 for ; Tue, 29 May 2012 09:32:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Swx67RYuNkAbkhmDLF5au+g9dmBhrRGwhyghbfkAphQ=; b=tynJHz1291venDXdnRrhMvvvEhwfg2NpsvgoJWWYq5RnkVZdOTf7B36Q8jsZARjpoD 4AyyWczNesEDaacIbDNGRktACeBphlDWFsxzjwyGzgJsVhpyWJqnCbC4jlgrTj/7T5Xt 5yOjvvbCu49Wxn95B/Jzq7r9HvoTHLmZSmXMVl954O0xktqczJZiHMW5iOAMWEARK1fr ZNIh0qeI71cBzTPd25vc3hcc1yGnzWpaJ56dFh3Gpq3/yrs2koYj/XUlnX3b5Mf4oZ+a Eyu89k7AKTqM08AMi+/IeF8U9Wbmdcbg9DCIv+9sjaNVtEF+5nw5EMgiy7iyWngPoTD0 QSXQ== MIME-Version: 1.0 Received: by 10.220.156.10 with SMTP id u10mr13442128vcw.20.1338309138091; Tue, 29 May 2012 09:32:18 -0700 (PDT) Received: by 10.52.22.143 with HTTP; Tue, 29 May 2012 09:32:18 -0700 (PDT) In-Reply-To: References: Date: Tue, 29 May 2012 11:32:18 -0500 Message-ID: From: Mary Barnes To: Marshall Eubanks Content-Type: multipart/alternative; boundary=f46d04389093c68fdb04c12f603b Cc: clue Subject: Re: [clue] Phone call today? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 29 May 2012 16:32:19 -0000 --f46d04389093c68fdb04c12f603b Content-Type: text/plain; charset=ISO-8859-1 Sorry, the chairs goofed and didn't send a cancellation due to the U.S. holiday. On Tue, May 29, 2012 at 8:57 AM, Marshall Eubanks < marshall.eubanks@gmail.com> wrote: > It's on my schedule, but I don't see a discussion of it on list. > > Marshall > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > --f46d04389093c68fdb04c12f603b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sorry, the chairs goofed and didn't send a cancellation due to the U.S.= holiday.=A0

On Tue, May 29, 2012 at 8:57= AM, Marshall Eubanks <marshall.eubanks@gmail.com> = wrote:
It's on my schedule, but I don't see= a discussion of it on list.

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

--f46d04389093c68fdb04c12f603b-- From magnus.westerlund@ericsson.com Wed May 30 04:45:25 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A080C21F86A7 for ; Wed, 30 May 2012 04:45:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.199 X-Spam-Level: X-Spam-Status: No, score=-106.199 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3gT1iaFC2DUu for ; Wed, 30 May 2012 04:45:24 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 42D3421F86A0 for ; Wed, 30 May 2012 04:45:23 -0700 (PDT) X-AuditID: c1b4fb25-b7fbf6d000002e5d-34-4fc60852ae1b Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id B5.9B.11869.25806CF4; Wed, 30 May 2012 13:45:23 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.264.0; Wed, 30 May 2012 13:45:22 +0200 Message-ID: <4FC60852.2040900@ericsson.com> Date: Wed, 30 May 2012 13:45:22 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: clue@ietf.org References: <4FA93AC9.70604@ericsson.com> In-Reply-To: <4FA93AC9.70604@ericsson.com> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpjluLIzCtJLcpLzFFi42KZGfG3VjeY45i/webfHBb7T11mdmD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxo8H85gLnglVXFu2hrWBcRZ/FyMnh4SAicSNbxuZIWwxiQv3 1rN1MXJxCAmcYpS49voblLOcUeLYtaVgVbwC2hKbt39hB7FZBFQltt9aC2azCVhI3PzRyAZi iwoES7zYc4UVol5Q4uTMJyxdjBwcIkD2yyuCIGFhAXWJlqYjLCC2kICmxPve52CtnAJaEo/e 7GGCOEhS4uC/a2DjmQX0JKZcbWGEsOUlmrfOZobo1ZZoaOpgncAoOAvJtllIWmYhaVnAyLyK UTg3MTMnvdxIL7UoM7m4OD9Przh1EyMwLA9u+a26g/HOOZFDjNIcLErivNZb9/gLCaQnlqRm p6YWpBbFF5XmpBYfYmTi4JRqYGx6szBgT+SJXv2qtW8uL7eL6Di5envfvoPt0rExqbsvLL95 XegOW8Ws2WkbhcSrrb5Ki+m9PCrNvNEtTK0za87UM85C+yLP2v24tOGJ97+joTvPOqawZ5cn Ks6eHrnnf/O0O7s01X95+M54n9d7udxrwtENwVv3P7OIES8yfF+yOK8i6uHBagYlluKMREMt 5qLiRAB3IBPFGQIAAA== Subject: Re: [clue] CLUE Interim Dinner X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2012 11:45:25 -0000 Hi, A Gently reminder that if you want to join I appreciate that you fill in the doodle no later than tomorrow! Cheers Magnus On 2012-05-08 17:24, Magnus Westerlund wrote: > Interim participants, > > I have booked tables at Ardbeg Embassy in Old Town. This will be a pay > for your self dinner. > > This restaurant I have chosen for multiple reasons. The first is that > their menu provides a wide variety of Swedish dishes and dishes based on > Swedish ingredients. See the main courses here with English explanations > when you click a particular dish: > http://www.ardbegembassy.se/menu/varmratter/ > > The second reason is that they are one of Stockholm's best places to try > Swedish micro brewery beer. They of course has an excellent whiskey > collection also. > > I hope you find this interesting and want to join us. However, I need a > better estimate of how many that will participate in the dinner so that > I can ensure that we have an appropriate sized booking. It will also > affect if we need to consider a group menu or not. So please indicate if > you plan to participate by the 31st of May. > > http://www.doodle.com/bfpz6suvnbsqb7dd > > > > Restaurant: http://www.ardbegembassy.se/ > Location: http://g.co/maps/5uruj > > 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 > ---------------------------------------------------------------------- > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From allyn@cisco.com Wed May 30 22:03:30 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D4B111E8121 for ; Wed, 30 May 2012 22:03:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EU2p-o1wXsbj for ; Wed, 30 May 2012 22:03:29 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id E35D911E80E1 for ; Wed, 30 May 2012 22:03:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=allyn@cisco.com; l=1396; q=dns/txt; s=iport; t=1338440610; x=1339650210; h=mime-version:content-transfer-encoding:subject:date: message-id:from:to; bh=HzokX2nJVTydshofqikuvPlKKtKsWTYj/YbEZ8naw0U=; b=GpwKbJx5fRjm2Ctx9HESBgk1+bPDckcQX9DcQfmAz50gWuJpKFrOAUej RLB3pKxYVYULQyQ4rgRYwpNzHkswiy03+xudT64Q3aBCteAMe5GCAoQLc owum/u57O8roKVb+JN8vrFejnNXWJBkoplKEG7g15BulVakHT/r7q9zkz Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAMn6xk+rRDoH/2dsb2JhbABEhU2tNoESgQeCFwEBAQQSARANBEMOBgEIEQQBAQMCBgYXAQICAwFEBwEBBQQBBBMIGodoAZd7gSiNH5JWgSOJZYQ0MmADiECaZYFmgwA X-IronPort-AV: E=Sophos;i="4.75,688,1330905600"; d="scan'208";a="44495510" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-3.cisco.com with ESMTP; 31 May 2012 05:03:29 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q4V53TU9024240 for ; Thu, 31 May 2012 05:03:29 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); Wed, 30 May 2012 22:03:29 -0700 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: Wed, 30 May 2012 22:03:28 -0700 Message-ID: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC0798382C@xmb-sjc-221.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Version Notification fordraft-pepperell-clue-switched-attribute-00.txt Thread-Index: Ac0+6V7O0dcDAJo+Tvq8hIXiaH0DSgAAUbTQ From: "Allyn Romanow (allyn)" To: "CLUE" X-OriginalArrivalTime: 31 May 2012 05:03:29.0319 (UTC) FILETIME=[B7F55370:01CD3EEA] Subject: [clue] FW: New Version Notification fordraft-pepperell-clue-switched-attribute-00.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 31 May 2012 05:03:30 -0000 DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0 Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0KU2VudDogV2VkbmVzZGF5 LCBNYXkgMzAsIDIwMTIgOTo1NCBQTQ0KVG86IEFsbHluIFJvbWFub3cgKGFsbHluKQ0KQ2M6IGFu ZHkucGVwcGVyZWxsQHNpbHZlcmZsYXJlLmNvbTsgUm9iZXJ0IEhhbnNlbiAocm9oYW5zZTIpOyBC cmlhbiBCYWxkaW5vIChiYmFsZGlubykNClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlv biBmb3JkcmFmdC1wZXBwZXJlbGwtY2x1ZS1zd2l0Y2hlZC1hdHRyaWJ1dGUtMDAudHh0DQoNCkEg bmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1wZXBwZXJlbGwtY2x1ZS1zd2l0Y2hlZC1hdHRyaWJ1 dGUtMDAudHh0IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgQWxseW4gUm9tYW5v dyBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoNCkZpbGVuYW1lOgkgZHJhZnQt cGVwcGVyZWxsLWNsdWUtc3dpdGNoZWQtYXR0cmlidXRlDQpSZXZpc2lvbjoJIDAwDQpUaXRsZToJ CSBVc2Ugb2Ygc3dpdGNoZWQgY2FwdHVyZSBhdHRyaWJ1dGUgJmFtcDsgc3BhdGlhbCBjby1vcmRp bmF0ZXMgaW4gYWR2YW5jZWQgY2FzZXMNCkNyZWF0aW9uIGRhdGU6CSAyMDEyLTA1LTMxDQpXRyBJ RDoJCSBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCk51bWJlciBvZiBwYWdlczogNw0KDQpBYnN0cmFj dDoNCiAgIFRoaXMgZHJhZnQgZXhhbWluZXMgdGhlIGlzc3VlcyB3aXRoIGFkdmVydGlzaW5nICZx dW90O3N3aXRjaGVkJnF1b3Q7IGNhcHR1cmVzDQogICBpbiBDTFVFLCBhbmQgbWFrZXMgc29tZSBw cm9wb3NhbHMgZm9yIGhvdyB0byBzb2x2ZSB0aGUgaXNzdWVzDQogICBpbnZvbHZlZC4NCg0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIA0KDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQo= From allyn@cisco.com Wed May 30 22:03:39 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2626911E8101 for ; Wed, 30 May 2012 22:03:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ExkePr9OE+nc for ; Wed, 30 May 2012 22:03:38 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 2D98711E80E1 for ; Wed, 30 May 2012 22:03:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=allyn@cisco.com; l=1890; q=dns/txt; s=iport; t=1338440618; x=1339650218; h=mime-version:content-transfer-encoding:subject:date: message-id:from:to; bh=bZCk8ZqmfAgUOKe7aBdqNoP56sR0S22lERu1aQWkwIM=; b=H6c+rwaVufDjEx6S+SOczZw6jr8QQF3cAGSq8BfR2IZSGm+/FxnxP6Ot M54K759qTM3CYpOCFkT+xnSaoWNGBctrE4hEB8FUJmhOJdu/R4MZWaIe/ AHszCBF9/8M1xNfWZx05SQOah7KVDy4eETIQklYy5GadTRHir2TZKIT+Z g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFACr7xk+rRDoI/2dsb2JhbABEhU2tNoESgQeCFwEBAQQSARANBEMOBgEIEQQBAQMCBgYXAQICAwFEBwEBBQQBBBMIEweHaAGXe4EojR+SVYEjiWWENDJgA4hAmmWBZoMA X-IronPort-AV: E=Sophos;i="4.75,688,1330905600"; d="scan'208";a="46984813" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 31 May 2012 05:03:37 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q4V53bRJ002904 for ; Thu, 31 May 2012 05:03:37 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); Wed, 30 May 2012 22:03:37 -0700 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: Wed, 30 May 2012 22:03:37 -0700 Message-ID: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC0798382D@xmb-sjc-221.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Version Notification for draft-hansen-clue-consumer-layout-00.txt Thread-Index: Ac0+6Wv8CkD8m3+pTXqadMejIeNhTwAAU3Mg From: "Allyn Romanow (allyn)" To: "CLUE" X-OriginalArrivalTime: 31 May 2012 05:03:37.0554 (UTC) FILETIME=[BCDDE320:01CD3EEA] Subject: [clue] FW: New Version Notification for draft-hansen-clue-consumer-layout-00.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 31 May 2012 05:03:39 -0000 DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0 Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0KU2VudDogV2VkbmVzZGF5 LCBNYXkgMzAsIDIwMTIgOTo1NCBQTQ0KVG86IEFsbHluIFJvbWFub3cgKGFsbHluKQ0KQ2M6IGFu ZHkucGVwcGVyZWxsQHNpbHZlcmZsYXJlLmNvbTsgbWFyay5kdWNrd29ydGhAcG9seWNvbS5jb207 IFJvYmVydCBIYW5zZW4gKHJvaGFuc2UyKTsgQnJpYW4gQmFsZGlubyAoYmJhbGRpbm8pDQpTdWJq ZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWhhbnNlbi1jbHVlLWNvbnN1 bWVyLWxheW91dC0wMC50eHQNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWhhbnNlbi1j bHVlLWNvbnN1bWVyLWxheW91dC0wMC50eHQgaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRl ZCBieSBBbGx5biBSb21hbm93IGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0K RmlsZW5hbWU6CSBkcmFmdC1oYW5zZW4tY2x1ZS1jb25zdW1lci1sYXlvdXQNClJldmlzaW9uOgkg MDANClRpdGxlOgkJIFRoZSBuZWVkIGZvciBjb25zdW1lciBzcGF0aWFsIGluZm9ybWF0aW9uIGlu IENMVUUNCkNyZWF0aW9uIGRhdGU6CSAyMDEyLTA1LTMxDQpXRyBJRDoJCSBJbmRpdmlkdWFsIFN1 Ym1pc3Npb24NCk51bWJlciBvZiBwYWdlczogOQ0KDQpBYnN0cmFjdDoNCiAgIFRoaXMgZHJhZnQg aXMgZm9yIGRpc2N1c3Npb24gaW4gdGhlIENMVUUgd29ya2luZyBncm91cC4gIEl0IHByb3Bvc2Vz DQogICBhZGRpbmcgdGhlIGFiaWxpdHkgZm9yIHRoZSBjb25zdW1lciB0byBwcm92aWRlIHNwZWNp ZmljIGluZm9ybWF0aW9uDQogICB0byB0aGUgcHJvdmlkZXIuDQoNCiAgIFRoaXMgZG9jdW1lbnQg cHJvcG9zZXMgYWxsb3dpbmcgY29uc3VtZXJzIHRvIGluY2x1ZGUgc3BhdGlhbA0KICAgcGFyYW1l dGVycyBpbiB0aGVpciBjb25zdW1lciByZXF1ZXN0cyB0byBwcm92aWRlcnMgaW4gb3JkZXIgdG8N CiAgIGltcHJvdmUgdGhlIHByb3ZpZGVyJiMzOTtzIGFiaWxpdHkgdG8gYXNzaWduIG1lZGlhIHRv IHN0cmVhbXMgaW4gYSB3YXkNCiAgIHRoYXQgaXMgaGVscGZ1bCBmb3IgcmVuZGVyaW5nLiAgVGhl IHNvbHV0aW9uIHByb3Bvc2VkIGhlcmUgaXMgaW4NCiAgIHBhcnRpYWwgcmVzcG9uc2UgdG8gQ0xV RSBUYXNrICMxMCwgRG9lcyBGcmFtZXdvcmsgcHJvdmlkZSBzdWZmaWNpZW50DQogICBpbmZvIGZv ciByZWNlaXZlcj8NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQoNClRoZSBJRVRGIFNl Y3JldGFyaWF0DQo= From allyn@cisco.com Wed May 30 22:03:52 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DB2B11E8101 for ; Wed, 30 May 2012 22:03:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YPuodedsYyQu for ; Wed, 30 May 2012 22:03:52 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id DD55E11E80E1 for ; Wed, 30 May 2012 22:03:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1746; q=dns/txt; s=iport; t=1338440631; x=1339650231; h=mime-version:content-transfer-encoding:subject:date: message-id:from:to; bh=+NpQTsQhmt3nH/KChUH/oKp1LsJMhUmvIrn0Nv+wMDI=; b=foHLAY3RGah1nA3EthJghkgmzh4xZgf0v2TdNBxbnj3Dxa4SRdVVlBF2 eXhUxrW9M5v6vEIj+r85iGtKFl25qv607RZWXMHfUK6N0UZvbc86om/8y 40OfONTJcqQ3Az5/38o5WulpTescoj4kXSRDBm/UgzKE0rRRN279uq0aq M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAPb6xk+tJV2d/2dsb2JhbABEhU2tNoESgQeCFwEBAQQSARANBDQPDgYBCBEEAQEDAgYGFwECAgMBRAcBAQUEAQQTCBMHh2gBl3uBKI0fklaBI4llhDQyYAOIQJplgWaDAA X-IronPort-AV: E=Sophos;i="4.75,688,1330905600"; d="scan'208";a="85179704" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-9.cisco.com with ESMTP; 31 May 2012 05:03:51 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id q4V53okd016168 for ; Thu, 31 May 2012 05:03:51 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); Wed, 30 May 2012 22:03:51 -0700 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: Wed, 30 May 2012 22:03:50 -0700 Message-ID: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC0798382E@xmb-sjc-221.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Version Notification fordraft-romanow-clue-audio-rendering-tag-00.txt Thread-Index: Ac0+6paqECgZv9hPR362vGzjRrbN4wAACrsg From: "Allyn Romanow (allyn)" To: "CLUE" X-OriginalArrivalTime: 31 May 2012 05:03:51.0165 (UTC) FILETIME=[C4FAC2D0:01CD3EEA] Subject: [clue] FW: New Version Notification fordraft-romanow-clue-audio-rendering-tag-00.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 31 May 2012 05:03:52 -0000 DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0 Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0KU2VudDogV2VkbmVzZGF5 LCBNYXkgMzAsIDIwMTIgMTA6MDIgUE0NClRvOiBBbGx5biBSb21hbm93IChhbGx5bikNCkNjOiBh bmR5LnBlcHBlcmVsbEBzaWx2ZXJmbGFyZS5jb207IFJvYmVydCBIYW5zZW4gKHJvaGFuc2UyKTsg QnJpYW4gQmFsZGlubyAoYmJhbGRpbm8pDQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRp b24gZm9yZHJhZnQtcm9tYW5vdy1jbHVlLWF1ZGlvLXJlbmRlcmluZy10YWctMDAudHh0DQoNCkEg bmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1yb21hbm93LWNsdWUtYXVkaW8tcmVuZGVyaW5nLXRh Zy0wMC50eHQgaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBBbGx5biBSb21hbm93 IGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KRmlsZW5hbWU6CSBkcmFmdC1y b21hbm93LWNsdWUtYXVkaW8tcmVuZGVyaW5nLXRhZw0KUmV2aXNpb246CSAwMA0KVGl0bGU6CQkg VGhlIG5lZWQgZm9yIGF1ZGlvIHJlbmRlcmluZyB0YWcgbWVjaGFuaXNtIGluIHRoZSBDTFVFIEZy YW1ld29yaw0KQ3JlYXRpb24gZGF0ZToJIDIwMTItMDUtMzENCldHIElEOgkJIEluZGl2aWR1YWwg U3VibWlzc2lvbg0KTnVtYmVyIG9mIHBhZ2VzOiA4DQoNCkFic3RyYWN0Og0KICAgVGhlIHB1cnBv c2Ugb2YgdGhpcyBkcmFmdCBpcyBmb3IgZGlzY3Vzc2lvbiBpbiB0aGUgQ0xVRSB3b3JraW5nDQog ICBncm91cC4NCg0KICAgSXQgcHJvcG9zZXMgYWRkaW5nIGFuIGF1ZGlvIHJlbmRlcmluZyB0YWcg dG8gdGhlIENMVUUgZnJhbWV3b3JrDQogICBbSS1ELmlldGYtY2x1ZS1mcmFtZXdvcmtdLCB3aGlj aCBtYWtlcyBpdCBwb3NzaWJsZSBmb3IgdGhlIGNvbnN1bWVyDQogICB0byBjb3JyZWN0bHkgcmVu ZGVyIGF1ZGlvIHdpdGggcmVzcGVjdCB0byB2aWRlbyBpbiBhIG11bHRpc3RyZWFtDQogICB2aWRl byBjb25mZXJlbmNlLiAgVGhlIHNvbHV0aW9uIHByb3Bvc2VkIGlzIGluIHBhcnRpYWwgcmVzcG9u c2UgdG8NCiAgIENMVUUgVGFzayAjMTAsIERvZXMgRnJhbWV3b3JrIHByb3ZpZGUgc3VmZmljaWVu dCBpbmZvIGZvciByZWNlaXZlcj8NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQoNClRo ZSBJRVRGIFNlY3JldGFyaWF0DQo= From allyn@cisco.com Wed May 30 22:07:58 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4410621F867B for ; Wed, 30 May 2012 22:07:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HQWltX7VGGUf for ; Wed, 30 May 2012 22:07:56 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id AFE9521F8674 for ; Wed, 30 May 2012 22:07:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=allyn@cisco.com; l=3472; q=dns/txt; s=iport; t=1338440876; x=1339650476; h=mime-version:subject:date:message-id:from:to; bh=vJG1eiEP29txu4H3P9Y1N5aZe4jaNoqnpJYpg9oQMH4=; b=JbmI2awnRLew3tSqNMfJNFs3l4+NlOSUEVDWi2zJQh1luB1gnQjnxd0n oEemoMf0xxnkk4/dRFtB+WP2BIR6F3oHsk+2gHXIUX+Joak17AxotmBfB pE4z+q6J3DbXEJLIpFWAnytMxmOWaDwemnAE2/b5NDtRhm2B25i5IDZvl 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EANb7xk+rRDoJ/2dsb2JhbABEgkWxUIEHghkBBBIBCREDWwEMHgYYB1cBBBsah2gBl3yBKJ90j25gA4hAmmWBZoMA X-IronPort-AV: E=Sophos;i="4.75,688,1330905600"; d="scan'208,217";a="44496210" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 31 May 2012 05:07:56 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q4V57ufe016037 for ; Thu, 31 May 2012 05:07:56 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); Wed, 30 May 2012 22:07:55 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 x-cr-hashedpuzzle: CyY= OdU= AA7Z Ac0/ Bk4a C0zP ERio FD6S FLk1 GUh8 HD9C HpQX Ioxt JTxf J+VC KlXr; 1; YwBsAHUAZQBAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {693313C9-FB33-478F-95D5-407438AC8B00}; YQBsAGwAeQBuAEAAYwBpAHMAYwBvAC4AYwBvAG0A; Thu, 31 May 2012 05:07:52 GMT; MwAgAGkAZABzAA== MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD3EEB.55F77BB5" x-cr-puzzleid: {693313C9-FB33-478F-95D5-407438AC8B00} Content-class: urn:content-classes:message Date: Wed, 30 May 2012 22:07:52 -0700 Message-ID: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC07983832@xmb-sjc-221.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 3 ids Thread-Index: Ac0+61ST1Tj7r00zRVWepY4W5p/pAw== From: "Allyn Romanow (allyn)" To: "CLUE" X-OriginalArrivalTime: 31 May 2012 05:07:55.0363 (UTC) FILETIME=[56886B30:01CD3EEB] Subject: [clue] 3 ids X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 31 May 2012 05:07:58 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD3EEB.55F77BB5 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Folks, I just submitted 3 ids - one of Andy's, the other Rob's-=20 They are all for discussion on the ML and in particular during the upcoming interim. Mary thought it would be best to put our thoughts into id form for ease of access. =20 Two of the drafts - the layout one, and the audio rendering tag are in response to Task #10 - by and large. The third - on switched captures is more of a clarification and a related proposal for handling certain use cases involving switched captures. =20 Enjoy-- ------_=_NextPart_001_01CD3EEB.55F77BB5 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Folks,

I just submitted 3 ids – one of Andy’s, = the other Rob’s-

They are all for discussion on the ML and in = particular during the upcoming interim.

Mary thought it would be best to put our thoughts = into id  form for ease of access.

 

Two of the drafts – the layout one, and the = audio rendering tag are in response to Task #10 – by and = large.

The third – on switched captures is more of a clarification and a related proposal for handling certain use cases = involving switched captures.

 

Enjoy--

------_=_NextPart_001_01CD3EEB.55F77BB5-- From magnus.westerlund@ericsson.com Thu May 31 08:33:23 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E37421F8783 for ; Thu, 31 May 2012 08:33:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.217 X-Spam-Level: X-Spam-Status: No, score=-106.217 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MznCf54Ckg8k for ; Thu, 31 May 2012 08:33:23 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 90C1021F87A1 for ; Thu, 31 May 2012 08:33:21 -0700 (PDT) X-AuditID: c1b4fb30-b7f606d0000002be-dc-4fc78f408559 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 45.6B.00702.04F87CF4; Thu, 31 May 2012 17:33:20 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.264.0; Thu, 31 May 2012 17:33:20 +0200 Message-ID: <4FC78F3F.90405@ericsson.com> Date: Thu, 31 May 2012 17:33:19 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: clue@ietf.org References: <4FA93AC9.70604@ericsson.com> <4FC60852.2040900@ericsson.com> In-Reply-To: <4FC60852.2040900@ericsson.com> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpjluLIzCtJLcpLzFFi42KZGfG3Vteh/7i/wYbjihb7T11mdmD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxpTLzcwFP9kq5r9+yNzAeJW1i5GTQ0LAROL6ypXsELaYxIV7 69m6GLk4hAROMUq86OhggnCWM0q0Tb3NBFLFK6ApsePKRTYQm0VAVaJtwwWwbjYBC4mbPxrB 4qICwRIv9lxhhagXlDg58wlLFyMHhwiQ/fKKIEhYWEBdoqXpCAuILSTgKfG3dTNYK6eAjsSO j0uhjpOUOPjvGth4ZgE9iSlXWxghbHmJ5q2zmSF6tSUamjpYJzAKzkKybRaSlllIWhYwMq9i FM5NzMxJLzfXSy3KTC4uzs/TK07dxAgMy4NbfhvsYNx0X+wQozQHi5I4r57qfn8hgfTEktTs 1NSC1KL4otKc1OJDjEwcnFINjKxnBfc8vThn10SHZBepR+nr/pzxidMsdqld2985tX7/jLui H+ZdXhJtGHlq1/zUW993uZyac9YtdV1ot1nWpbp/qUKMd+Y83D55OadPWanEb9HX149oHhJ7 2atublD9ZZnZlNuFPqJX1vj9+FZ9TupdxoVv5wVmm30K9ohYv7nDWzb6UX5FEr8SS3FGoqEW c1FxIgCnzTEbGQIAAA== Subject: Re: [clue] CLUE Interim Dinner X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 31 May 2012 15:33:23 -0000 Clue Interim Dinner Participants, We will be a fairly many close to 20. This means that the available menu will be restricted to two dishes per course. I plan to select dishes that are Swedish or at least has very Swedish ingredients. If you have food allergies or intolerances please send me a private email with what they are ASAP. So that I can ensure that you will not be without suitable dishes. 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 pkyzivat@alum.mit.edu Thu May 31 10:27:27 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29C3321F875A for ; Thu, 31 May 2012 10:27:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[AWL=-0.002, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wAccTHIk6qSS for ; Thu, 31 May 2012 10:27:26 -0700 (PDT) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [76.96.59.211]) by ietfa.amsl.com (Postfix) with ESMTP id 5A3A121F8759 for ; Thu, 31 May 2012 10:27:26 -0700 (PDT) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by QMTA11.westchester.pa.mail.comcast.net with comcast id GgfT1j0051ZXKqc5BhTQL6; Thu, 31 May 2012 17:27:24 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta21.westchester.pa.mail.comcast.net with comcast id GhTQ1j00507duvL3hhTQpv; Thu, 31 May 2012 17:27:24 +0000 Message-ID: <4FC7A9FB.4080608@alum.mit.edu> Date: Thu, 31 May 2012 13:27:23 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: clue@ietf.org References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC0798382E@xmb-sjc-221.amer.cisco.com> In-Reply-To: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC0798382E@xmb-sjc-221.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] draft-romanow-clue-audio-rendering-tag-00.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 31 May 2012 17:27:27 -0000 I'm really happy to see drafts such as this one and the others sent out at the same time. They really communicate a lot of thinking and really help to facilitate conversation. I do have some basic questions about the functionality proposed in this draft. (Note that I'm not well versed in media processing, so I won't feel bad to be told that my questions make no sense.) IIUC, RTP (together with some basic signaling in SDP) has a mechanism to specify lip-sync, based on matching CNAME values between an audio and video stream. Why is the lip-sync mechanism not sufficient for the consumer to match a particular packet from an audio capture to the screen(s) that displayed recent video packets? I do see a different but related problem that I don't think has been addressed yet: how do I ensure that I have selected the proper set of audio captures that will carry the audio corresponding to the set of video captures that I have selected? Thanks, Paul On 5/31/12 1:03 AM, Allyn Romanow (allyn) wrote: > > > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Wednesday, May 30, 2012 10:02 PM > To: Allyn Romanow (allyn) > Cc: andy.pepperell@silverflare.com; Robert Hansen (rohanse2); Brian Baldino (bbaldino) > Subject: New Version Notification fordraft-romanow-clue-audio-rendering-tag-00.txt > > A new version of I-D, draft-romanow-clue-audio-rendering-tag-00.txt has been successfully submitted by Allyn Romanow and posted to the IETF repository. > > Filename: draft-romanow-clue-audio-rendering-tag > Revision: 00 > Title: The need for audio rendering tag mechanism in the CLUE Framework > Creation date: 2012-05-31 > WG ID: Individual Submission > Number of pages: 8 > > Abstract: > The purpose of this draft is for discussion in the CLUE working > group. > > It proposes adding an audio rendering tag to the CLUE framework > [I-D.ietf-clue-framework], which makes it possible for the consumer > to correctly render audio with respect to video in a multistream > video conference. The solution proposed is in partial response to > CLUE Task #10, Does Framework provide sufficient info for receiver? > > > > > The IETF Secretariat > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From rohanse2@cisco.com Thu May 31 10:51:09 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2504221F861A for ; Thu, 31 May 2012 10:51:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gEMyjkR4JIYq for ; Thu, 31 May 2012 10:51:08 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id F0AEC21F861C for ; Thu, 31 May 2012 10:51:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rohanse2@cisco.com; l=3727; q=dns/txt; s=iport; t=1338486668; x=1339696268; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=ESUAiF2YgUpxIpB6tXPDsu6QhpDPF73FT60OCvq/4yU=; b=jm0cUmyqk91I6hhsArGmKZSR5FkAz3fHpDo/IUlqsOSnjaUXVP9vl/bg fBdDDPhopovO6K/ja/sG7by1mh3Z6YHKhQkvO9QOEg6B+FV9vNuREWCid 5UqKvPIU3P8WSmgWD7YhJ1hLpohT74JtQVOUElnWDDLOcCdFE+QBYPNwr w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgwFADqux0+Q/khN/2dsb2JhbABEgx2wd4EHghgBAQEEAQEBDwElMAYKDQQLEQQBAQEJFggHCQMCAQIBFR8JCBMGAgEBFweHaQuZKZ9MBIsRhUYDlRiFT4g+gWaCYQ X-IronPort-AV: E=Sophos;i="4.75,693,1330905600"; d="scan'208";a="73883505" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 31 May 2012 17:51:04 +0000 Received: from [10.47.196.154] ([10.47.196.154]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q4VHp4YE007877 for ; Thu, 31 May 2012 17:51:04 GMT Message-ID: <4FC7AF8B.9050506@cisco.com> Date: Thu, 31 May 2012 18:51:07 +0100 From: Robert Hansen User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: clue@ietf.org References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC0798382E@xmb-sjc-221.amer.cisco.com> <4FC7A9FB.4080608@alum.mit.edu> In-Reply-To: <4FC7A9FB.4080608@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] draft-romanow-clue-audio-rendering-tag-00.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 31 May 2012 17:51:09 -0000 Hi Paul, As you say, CNAME is used for lipsyncby establishing which RTP streams share a common clock. However, in multistream there may be a more granular positional association than just this synchronisation. For instance, in a case where an endpoint produces three video streams and one audio stream, all four streams would likely share a common clock and hence can be sychronised. However, at any given time the audio may come from one of three microphones associated with the three positions, and hence at the far end we would want it to be played out in that position. RTCP SDES packets also has the property that they are not received as frequently or in sync with the RTP media packets; this isn't a particular problem for lipsync, as the adjustments required to sync streams are generally small and in the case of audio can be concealed in moments of silence. However, starting to play out audio from one speaker and then moving it a few seconds later when the SDES packet arrives is much more noticeable to users. Rob On 31/05/2012 18:27, Paul Kyzivat wrote: > I'm really happy to see drafts such as this one and the others sent out > at the same time. They really communicate a lot of thinking and really > help to facilitate conversation. > > I do have some basic questions about the functionality proposed in this > draft. (Note that I'm not well versed in media processing, so I won't > feel bad to be told that my questions make no sense.) > > IIUC, RTP (together with some basic signaling in SDP) has a mechanism to > specify lip-sync, based on matching CNAME values between an audio and > video stream. Why is the lip-sync mechanism not sufficient for the > consumer to match a particular packet from an audio capture to the > screen(s) that displayed recent video packets? > > I do see a different but related problem that I don't think has been > addressed yet: how do I ensure that I have selected the proper set of > audio captures that will carry the audio corresponding to the set of > video captures that I have selected? > > Thanks, > Paul > > On 5/31/12 1:03 AM, Allyn Romanow (allyn) wrote: >> >> >> -----Original Message----- >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >> Sent: Wednesday, May 30, 2012 10:02 PM >> To: Allyn Romanow (allyn) >> Cc: andy.pepperell@silverflare.com; Robert Hansen (rohanse2); Brian >> Baldino (bbaldino) >> Subject: New Version Notification >> fordraft-romanow-clue-audio-rendering-tag-00.txt >> >> A new version of I-D, draft-romanow-clue-audio-rendering-tag-00.txt >> has been successfully submitted by Allyn Romanow and posted to the >> IETF repository. >> >> Filename: draft-romanow-clue-audio-rendering-tag >> Revision: 00 >> Title: The need for audio rendering tag mechanism in the CLUE Framework >> Creation date: 2012-05-31 >> WG ID: Individual Submission >> Number of pages: 8 >> >> Abstract: >> The purpose of this draft is for discussion in the CLUE working >> group. >> >> It proposes adding an audio rendering tag to the CLUE framework >> [I-D.ietf-clue-framework], which makes it possible for the consumer >> to correctly render audio with respect to video in a multistream >> video conference. The solution proposed is in partial response to >> CLUE Task #10, Does Framework provide sufficient info for receiver? >> >> >> >> >> The IETF Secretariat >> _______________________________________________ >> 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 From pkyzivat@alum.mit.edu Thu May 31 11:05:26 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 251C321F8718 for ; Thu, 31 May 2012 11:05:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[AWL=-0.002, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wv2UkuL34DF7 for ; Thu, 31 May 2012 11:05:24 -0700 (PDT) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [76.96.59.228]) by ietfa.amsl.com (Postfix) with ESMTP id 7F97721F8720 for ; Thu, 31 May 2012 11:05:23 -0700 (PDT) Received: from omta19.westchester.pa.mail.comcast.net ([76.96.62.98]) by qmta15.westchester.pa.mail.comcast.net with comcast id GfrJ1j00A27AodY5Fi5Nqo; Thu, 31 May 2012 18:05:22 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta19.westchester.pa.mail.comcast.net with comcast id Gi5N1j01y07duvL3fi5Nzm; Thu, 31 May 2012 18:05:22 +0000 Message-ID: <4FC7B2E1.9050603@alum.mit.edu> Date: Thu, 31 May 2012 14:05:21 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: CLUE Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [clue] negotiation between consumer and provider X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 31 May 2012 18:05:26 -0000 I just read through the three new drafts: draft-pepperell-clue-switched-attribute draft-hansen-clue-consumer-layout draft-romanow-clue-audio-rendering-tag All three of these propose a mechanism that, AFAIK, is new to CLUE: it is that data included by the consumer in its selection message to the provider might alter in a fundamental way what content is included in the selected captures. More specifically, its proposed that the consumer describe something about its use of the captures, and that then the provider will tailor what is sent in the captures. This seems to be a change from the model that has been previously discussed - the three message exchange: capabilities/advertisement/selection. As I understand that model, the provider can use the capabilities from the consumer to tailor what it advertises to the consumer, and then the consumer selects from what has been advertised. ISTM that its intrinsic in the selection process that the captures that have been advertised have some specific semantic that is preserved when they are selected. This new model seems to alter that relationship. I don't mean to imply that it is wrong, only that it seems like a fundamental change. It also seems to me that at least part of what has been proposed in these drafts could be addressed by the prior model - especially since the content of the capabilities message is yet to be defined. For instance, If the consumer were to specify that it has three screens and a speaker with each screen, then an MCU as provider could construct an advertisement containing a single scene where all the entries contain three captures. These would presumably be alternative ways of rendering the conference on three screens. It wouldn't require the consumer to again decide its capabilities as part of the selection. I think it might also increase the likelihood that the MCU could reuse the same captures it provides for more than one endpoint. Thanks, Paul (as individual) From pkyzivat@alum.mit.edu Thu May 31 11:17:05 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03C7511E80DB for ; Thu, 31 May 2012 11:17:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[AWL=-0.302, BAYES_00=-2.599, J_CHICKENPOX_45=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TgTalvpiGjZ7 for ; Thu, 31 May 2012 11:17:04 -0700 (PDT) Received: from qmta01.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [76.96.62.24]) by ietfa.amsl.com (Postfix) with ESMTP id 1785311E809F for ; Thu, 31 May 2012 11:17:03 -0700 (PDT) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta01.westchester.pa.mail.comcast.net with comcast id Gg3K1j0011c6gX851iH3Bq; Thu, 31 May 2012 18:17:03 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta23.westchester.pa.mail.comcast.net with comcast id GiH21j01407duvL3jiH3hi; Thu, 31 May 2012 18:17:03 +0000 Message-ID: <4FC7B59E.4010307@alum.mit.edu> Date: Thu, 31 May 2012 14:17:02 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: clue@ietf.org References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC0798382E@xmb-sjc-221.amer.cisco.com> <4FC7A9FB.4080608@alum.mit.edu> <4FC7AF8B.9050506@cisco.com> In-Reply-To: <4FC7AF8B.9050506@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] draft-romanow-clue-audio-rendering-tag-00.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 31 May 2012 18:17:05 -0000 On 5/31/12 1:51 PM, Robert Hansen wrote: > Hi Paul, > > As you say, CNAME is used for lipsyncby establishing which RTP streams > share a common clock. Is the CNAME used for this always derived from the SSRC, or can it be derived from a CSRC? > However, in multistream there may be a more granular positional > association than just this synchronisation. For instance, in a case > where an endpoint produces three video streams and one audio stream, all > four streams would likely share a common clock and hence can be > sychronised. However, at any given time the audio may come from one of > three microphones associated with the three positions, and hence at the > far end we would want it to be played out in that position. In such a case, couldn't the provider use three different CSRCs to indicate which mic was being sent? Or use three different SSRCs for that purpose, if necessary to identify the correlation. > RTCP SDES packets also has the property that they are not received as > frequently or in sync with the RTP media packets; this isn't a > particular problem for lipsync, as the adjustments required to sync > streams are generally small and in the case of audio can be concealed in > moments of silence. However, starting to play out audio from one speaker > and then moving it a few seconds later when the SDES packet arrives is > much more noticeable to users. I had assumed that the SSRC:CNAME correlation was cached. If so, I would think this wouldn't normally be a problem. The point of my question is just to see if there is a way to use existing mechanisms rather than invent new ones. Thanks, Paul > Rob > > On 31/05/2012 18:27, Paul Kyzivat wrote: >> I'm really happy to see drafts such as this one and the others sent out >> at the same time. They really communicate a lot of thinking and really >> help to facilitate conversation. >> >> I do have some basic questions about the functionality proposed in this >> draft. (Note that I'm not well versed in media processing, so I won't >> feel bad to be told that my questions make no sense.) >> >> IIUC, RTP (together with some basic signaling in SDP) has a mechanism to >> specify lip-sync, based on matching CNAME values between an audio and >> video stream. Why is the lip-sync mechanism not sufficient for the >> consumer to match a particular packet from an audio capture to the >> screen(s) that displayed recent video packets? >> >> I do see a different but related problem that I don't think has been >> addressed yet: how do I ensure that I have selected the proper set of >> audio captures that will carry the audio corresponding to the set of >> video captures that I have selected? >> >> Thanks, >> Paul >> >> On 5/31/12 1:03 AM, Allyn Romanow (allyn) wrote: >>> >>> >>> -----Original Message----- >>> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >>> Sent: Wednesday, May 30, 2012 10:02 PM >>> To: Allyn Romanow (allyn) >>> Cc: andy.pepperell@silverflare.com; Robert Hansen (rohanse2); Brian >>> Baldino (bbaldino) >>> Subject: New Version Notification >>> fordraft-romanow-clue-audio-rendering-tag-00.txt >>> >>> A new version of I-D, draft-romanow-clue-audio-rendering-tag-00.txt >>> has been successfully submitted by Allyn Romanow and posted to the >>> IETF repository. >>> >>> Filename: draft-romanow-clue-audio-rendering-tag >>> Revision: 00 >>> Title: The need for audio rendering tag mechanism in the CLUE Framework >>> Creation date: 2012-05-31 >>> WG ID: Individual Submission >>> Number of pages: 8 >>> >>> Abstract: >>> The purpose of this draft is for discussion in the CLUE working >>> group. >>> >>> It proposes adding an audio rendering tag to the CLUE framework >>> [I-D.ietf-clue-framework], which makes it possible for the consumer >>> to correctly render audio with respect to video in a multistream >>> video conference. The solution proposed is in partial response to >>> CLUE Task #10, Does Framework provide sufficient info for receiver? >>> >>> >>> >>> >>> The IETF Secretariat >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >>> >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From ron.even.tlv@gmail.com Thu May 31 13:14:59 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C88D321F8564 for ; Thu, 31 May 2012 13:14:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.463 X-Spam-Level: X-Spam-Status: No, score=-3.463 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ERsXQrmSHEou for ; Thu, 31 May 2012 13:14:59 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id ECE5C21F855F for ; Thu, 31 May 2012 13:14:58 -0700 (PDT) Received: by werb13 with SMTP id b13so1032930wer.31 for ; Thu, 31 May 2012 13:14:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language; bh=uUv23+o/JxIw+N5r/Z5TxYf9Oj1Uqz8WQoz3pYrqTqs=; b=TmaCaOf/+HlDqRj23p5+CY8E/+ArWutB8k7iLCPm793k3CMROpevKrpkeqyeBy6axJ bSQt+W4/Xh7WiuOGj4wrudHJo3beO9V/GuZAzrH2J+RXRCFswTDGhPPVgIpdMWg+PYZb IZu4clrSopdM8uXdsdZvzSA6pHWqe/vwKSzeYjgZUfx6XS0j6eE4GnlslEU0qQ7J6BAU WVnT+Eq//EpcO2zA3q1juhNEArhG0T0JGPkVmkBLjGxoIY4BNNcsQZRlL519jwGVexe+ 2NeJ+9BVWcdw/OfXcyTFxLmMUft0EjP9MUFVWM+R/mjH6Mv7Fwt87nGFz3UWoioBlJ6Q FaSg== Received: by 10.216.54.206 with SMTP id i56mr62044wec.28.1338495297901; Thu, 31 May 2012 13:14:57 -0700 (PDT) Received: from windows8d787f9 (bzq-79-177-198-116.red.bezeqint.net. [79.177.198.116]) by mx.google.com with ESMTPS id d10sm9608209wiy.3.2012.05.31.13.14.55 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 31 May 2012 13:14:56 -0700 (PDT) From: "Roni Even" To: "'Allyn Romanow \(allyn\)'" , "'CLUE'" References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC0798382E@xmb-sjc-221.amer.cisco.com> In-Reply-To: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC0798382E@xmb-sjc-221.amer.cisco.com> Date: Thu, 31 May 2012 23:12:31 +0300 Message-ID: <4fc7d140.ea51b40a.4f38.40c9@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: Ac0+6paqECgZv9hPR362vGzjRrbN4wAACrsgAB+hNdA= Content-Language: en-us Subject: Re: [clue] FW: New Version Notification fordraft-romanow-clue-audio-rendering-tag-00.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 31 May 2012 20:14:59 -0000 Hi, I think that Magnus has a more general proposal in http://tools.ietf.org/id/draft-westerlund-avtext-rtcp-sdes-srcname-00.txt Roni Even > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Allyn Romanow (allyn) > Sent: Thursday, May 31, 2012 8:04 AM > To: CLUE > Subject: [clue] FW: New Version Notification fordraft-romanow-clue- > audio-rendering-tag-00.txt > > > > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Wednesday, May 30, 2012 10:02 PM > To: Allyn Romanow (allyn) > Cc: andy.pepperell@silverflare.com; Robert Hansen (rohanse2); Brian > Baldino (bbaldino) > Subject: New Version Notification fordraft-romanow-clue-audio- > rendering-tag-00.txt > > A new version of I-D, draft-romanow-clue-audio-rendering-tag-00.txt has > been successfully submitted by Allyn Romanow and posted to the IETF > repository. > > Filename: draft-romanow-clue-audio-rendering-tag > Revision: 00 > Title: The need for audio rendering tag mechanism in the > CLUE Framework > Creation date: 2012-05-31 > WG ID: Individual Submission > Number of pages: 8 > > Abstract: > The purpose of this draft is for discussion in the CLUE working > group. > > It proposes adding an audio rendering tag to the CLUE framework > [I-D.ietf-clue-framework], which makes it possible for the consumer > to correctly render audio with respect to video in a multistream > video conference. The solution proposed is in partial response to > CLUE Task #10, Does Framework provide sufficient info for receiver? > > > > > The IETF Secretariat > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue