From apeppere@gmail.com Wed Aug 1 06:07:01 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 70C4511E85A0 for ; Wed, 1 Aug 2012 06:07:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, 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 HrHFPRfOcawJ for ; Wed, 1 Aug 2012 06:06:58 -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 205E611E8533 for ; Wed, 1 Aug 2012 06:06:57 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so4651653wgb.13 for ; Wed, 01 Aug 2012 06:06:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; bh=os/bkKNiUAo6QczOIAN7Jiee3Bex6S4it/uvSljmvcY=; b=V3+/Jqt+v1x6JMc5TWSdvMR6JXg2/NvlojGoXD5mFxZVN14j1ZQd8IplR5hb3eDO12 2y+h3JXbLPTp8aGdoe1oFpvytlYyHqelvz7o1djCvHIBqv2Ew5xKoH5OgWnVavlsGa+c Vyv90mcpH7XXznPajl4Q+kcL7g3vCo4jedt0rlXia25a+0wrInS3L3O8PuEnQz32GP22 BrRNO77CtVffE399NDH9fW4Bgr6E4NPZTlMaRoeB6lwY2ZXZi49ttqLUlWqcSo5IGmfF Cpjca4m1K/0tbqL1yaY/yEupaI8Q7O1eZ0cdcIH7ug9rl1a2DnxWQToEAm2SkC/sw9AR cEwg== Received: by 10.217.6.12 with SMTP id x12mr7928421wes.176.1343826415951; Wed, 01 Aug 2012 06:06:55 -0700 (PDT) Received: from [10.5.220.76] ([212.183.140.19]) by mx.google.com with ESMTPS id t7sm8629651wix.6.2012.08.01.06.06.02 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 01 Aug 2012 06:06:53 -0700 (PDT) References: <003e01cd6f84$86f63120$94e29360$@gmail.com> In-Reply-To: <003e01cd6f84$86f63120$94e29360$@gmail.com> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-1417C101-7C5C-4B5B-A306-C6B511C851D7 Message-Id: X-Mailer: iPhone Mail (9B206) From: Andrew Pepperell Date: Wed, 1 Aug 2012 14:05:53 +0100 To: Roni Even Cc: CLUE Subject: Re: [clue] a few issues on data model draft 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, 01 Aug 2012 13:07:01 -0000 --Apple-Mail-1417C101-7C5C-4B5B-A306-C6B511C851D7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Roni, While what you say seems to be applicable here to CLUE, a couple of things s= pring to mind: - it's not clear that we'll be declaring SSRC values in SDP as webrtc dies, s= o being able to specify imageattr there might not be of use - even if we were, there's no obvious defined SSRC <-> media capture mapping= being considered. Specifically, at offer-time the provider wouldn't know wh= ich SSRCs were to be used for which captures and so wouldn't be able to dete= rmine which imageattr values to assign with which SSRC values. I can understand how what you describe works fine for webrtc - did you have a= scheme in mind for tackling the above entwined issues (especially the secon= d one) ? Regards, Andy On 1 Aug 2012, at 02:25, "Roni Even" wrote: > Andy, > The image attribute provides a better solution to allow the consumer to a= sk for a preferred image size which is not only the aspect ratio but the res= olution and pixel aspect ratio. It can be specified per SSRC http://tools.i= etf.org/html/draft-lennox-mmusic-sdp-source-selection-03 > The consensus in RTCweb was to use this solution based on http://tools.ie= tf.org/html/draft-alvestrand-rtcweb-resolution-00 > =20 > Roni > =20 > From: Andy Pepperell [mailto:apeppere@gmail.com]=20 > Sent: 01 August, 2012 1:41 AM > To: Allyn Romanow (allyn) > Cc: Espen Berger (espeberg); Roni Even; CLUE > Subject: Re: [clue] a few issues on data model draft > =20 > >>>Currently it is not possible to tell whether a remote video source is n= atively 4:3 or 16:9, for instance. > >>>If we have this, there might usefully be a "PREFERRED-ASPECT-RATIO" in t= he consumer's stream selection message as part of the (e.g. in " / "). >=20 > >>Roni: RE: No need, first of all it does not work with switched capture t= hat may have different aspect ratios. Also this is available in the SDP as w= ell as a way for receiver to ask for specific ratio using the SDP image attr= ibute. >=20 > >AR =E2=80=93 I=E2=80=99ll let Andy respond to this >=20 > Many apologies for not doing so until now... >=20 > Roni, I think you're right in that at least the native aspect ratio as pot= entially expressed in a provider's capture advertisement wouldn't work for t= he switched capture case (or at least wouldn't work all the time - for the e= ndpoint case where the switched capture was a dynamic choice between one of t= he "real" cameras' image then it would be possible (and straightforward) to a= ttach the same native aspect ratio to the switched capture as was applicable= to the non-switched captures). Even if it were impossible to attach a "nati= ve aspect ratio" to the switched case, to my mind this doesn't necessarily t= ake away from the validity in this scenario of the consumer supplying a "pre= ferred aspect ratio" in its stream selection message. >=20 > re: use of "imageattr" in the SDP, it's definitely pertinent here; potenti= ally this has some issues in relation to CLUE: >=20 > - it would have to be applied on a per m line basis (excluding payload typ= e differences) rather than per capture - within CLUE there would be a need (= or at least use) of the aspect ratio specification being more fine-grained a= nd separately specifiable per capture (this may depend in part on how we eve= ntually choose to manage main vs slides video in terms of RTP session associ= ation though). >=20 > - by being in SDP, it's presumably the case that to correctly signal to th= e consumer when, say, a 4:3 presentation source had been connected would req= uire an additional offer / answer cycle (and similarly if that source were t= o be disconnected and a new 16:9 source attached) - this seems slightly less= lightweight than the equivalent operation would be if its scope were restri= cted to just the CLUE provider capture advertisement. As a side point, it al= so seems more heavyweight than SIP without the use of imageattr too, where p= resumably the only impact of connecting such a presentation source would be a= BFCP exchange. >=20 > I'm happy to own up here to not having seen this attribute being present i= n devices' SDP, so if any of the above are inaccurate due to my ignorance on= this, I apologise. It would certainly be interesting to get some sort of pi= cture of the adoption of "imageattr" within the vendor community - I don't r= ecall seeing this in use, but most of my exposure has been to systems not ne= cessarily running recent software versions. Obviously if the already-defined= "imageattr" does all we'd like within CLUE, then we should use this already= -defined scheme. >=20 > Regards, >=20 > Andy >=20 >=20 > On Sun, Jul 29, 2012 at 4:58 AM, Allyn Romanow (allyn) w= rote: > Hi Espen, > Thanks for your comments- > Please see below- > Also inline in response to your inline J > =20 > From: Espen Berger (espeberg)=20 > Sent: Monday, July 23, 2012 8:27 AM > To: Allyn Romanow (allyn); Roni Even; 'CLUE' >=20 > Subject: RE: [clue] a few issues on data model draft > =20 > I have two questions to the data model draft. > =20 > The first questions is related to naming differences between the CLUE fram= ework and the CLUE data model. Some examples of differences. the framework u= ses Description and the data model uses capture-scene-text, the framework us= es capture and the data model uses capture-description . Isn=E2=80=99t it na= tural that both documents share the same vocabulary? > =20 > AR =E2=80=93 Christian also brought this up. I believe that the document= s will not have the same vocabulary =E2=80=93 but the concepts are the same.= The framework was written first and it=E2=80=99s goal is to describe th= ings as clearly as possible (we=E2=80=99re not done with that=E2=80=A6). The= data model is more formal and the language there is not casual. It was deve= loped after the framework, so it sort of distils the ideas in the framework.= =20 > =20 > If there is a discrepancy of meaning, that is an issue and we should defin= itely sort it out. But in terms of language, I think it=E2=80=99s fine to ei= ther leave it different or change the framework at some point to be more in= keeping with the data model.. but I think it=E2=80=99s a good idea to do th= at later when the data model is about agreed upon. =20 > =20 > I=E2=80=99ve put this on the list for discussion at the IETF meeting on We= ds. = =20 > =20 > The second questions is related to the concept of doing a data model as th= e basis for both advertisement and configuration messages. Playing around wi= th some XML examples messages it=E2=80=99s not obvious that the two messages= types share a common data model. I do see similarities between the initial a= dvertisement, the current active configuration and the advantages of be able= to describe the state of a running CLUE system. Assume this will be sorted o= ut when we look at the details of how to do configuration in CLUE. =20 > =20 > AR - Okay, this is interesting. Guess I=E2=80=99ll have to wait to see mor= e specifically what issues arise. > =20 > Additional comments inline. > =20 > -Espen > =20 > =20 > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Al= lyn Romanow (allyn) >=20 > Sent: 18. juli 2012 23:00 > To: Roni Even; 'CLUE' > Subject: Re: [clue] a few issues on data model draft > =20 > Hi Roni, > Sure, these are easy to add- > thanks > =20 > From: Roni Even [mailto:ron.even.tlv@gmail.com] > Sent: Wednesday, July 18, 2012 2:56 PM > To: Allyn Romanow (allyn); 'CLUE' > Subject: RE: [clue] a few issues on data model draft > =20 > Hi, > Reviewed the draft, inline for your question (BTW: not all the new attribu= tes here are in BOLD for example captureID) > =20 > Other comments > =20 > 1. Need to add axis of capture to the media capture (now in the fram= ework) >=20 > 2. The capture scene text and language should be sets of (text, lang= uage), I think is not the current structure >=20 > =20 > Thanks > Roni > =20 > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Al= lyn Romanow (allyn) > Sent: 18 July, 2012 3:22 AM > To: CLUE (clue@ietf.org) > Subject: [clue] a few issues on data model draft > =20 > Folks, >=20 > There are several issues related to the data model that we=E2=80=99d like u= s to consider. These are things that are not exactly the same as in the fram= ework, to a lesser or greater extent. They were brought up during the data m= odel presentation at the interim meeting. I wonder if we could work on resol= ving them? >=20 > List based on draft-romanow-clue-data-model-01 >=20 > 1. Any problem with using media-type for capture attribute as described i= n the draft? >=20 > RE: OK >=20 >=20 > EBE> Supported, since its allow us to join the audio and video encodings i= nto a single list of encodings. > 2. Any problem with using content-type for capture attribute as described= in the draft? >=20 > RE: I did not see any difference from the framework in whi= ch case I am OK. > EBE> The framework use the =E2=80=98content=E2=80=99 name a= nd the data model the =E2=80=98content-type=E2=80=99 name. Why not use the s= ame name? =20 > AR- as above >=20 > 3. DERIVED for capture attribute- Should we have a variable called someth= ing like DERIVED, that takes various values, one of which is composed. That w= ould mean that if DERIVED is not =3Dcomposed, that the capture is not compos= ed, and if it =3Dcomposed then it is. I don=E2=80=99t have another descripto= r to propose now, but there could be others either now or later. >=20 > Why this change from the framework? I think it is more general than compos= ed Boolean, yet semantically similar. >=20 > This does not prevent us from having qualifiers to describe composed, to h= elp distinguish between different composed captures, as has been discussed= . Also, it needs to be possible to have multiple values for =E2=80=9CDERIVED= =E2=80=9D, that is the values should not be mutually exclusive. >=20 > RE: I am OK if this is for future extension but am not su= re about the structure the high level derived which has Compose and future s= omething (not sure what). The composed has a value (true, false) and child e= lements for extensions . Is this the proposed structure? > EBE> I like the idea of describing the origin of the capture with an attri= bute that is more extensible than a Boolean. What about creating enumerated v= alues for the two origins we are currently discussing. We have =E2=80=98comp= osed=E2=80=99 (composed=3Dtrue) meaning that the media has been changed in s= ome way and original (composed=3Dfalse). > 4. Leave switched as a Boolean as in framework. The proposal in the draft= seems infeasible =E2=80=93 we don=E2=80=99t want CLUE to have to include a= ll the ways in which products might want to implement switching. It would be= better to make this more general, but we have no suggestion for it at prese= nt- it does not really match the meaning of a derived capture. >=20 > RE: I think that if we have the extension for composed as I= outlined above we can have similar here. >=20 > 5. As part of the capture description, should we have a parameter NATIVE-= ASPECT-RATIO, which indicates the aspect ratio for the capture if there is o= ne, such as 4:3 for a video camera? The reason is that it can help rendering= . >=20 >=20 >=20 > Currently it is not possible to tell whether a remote video source is nati= vely 4:3 or 16:9, for instance. If we have this, there might usefully be a "= PREFERRED-ASPECT-RATIO" in the consumer's stream selection message as part o= f the (e.g. in " / "). > RE: No need, first of all it does not work with switched c= apture that may have different aspect ratios. Also this is available in the S= DP as well as a way for receiver to ask for specific ratio using the SDP ima= ge attribute. > EBE> The image attribute (RFC6236) document talks about image resolution a= nd picture aspect ratio, and how they relates to codec specific parameters l= ike h264 max-fs and max-mbps. An attribute can have a single value, a list o= f values or a range. > 6. Multiplex ID =E2=80=93 Value sent by consumer in its stream selection= message with the encoding id and capture id. This is the mechanism by which= the consumer tells the provider which multiplex id to generate that stream w= ith, so that the consumer can demultiplex the stream correctly when receivin= g it. >=20 > This is the link between RTP and CLUE as discussed in draft-lennox-clue-rt= p-usage. > Think should probably be re-named. >=20 > RE: I do not see the need the mapping is to the capture ID w= hich is a numeric value. See http://tools.ietf.org/html/draft-even-clue-rtp-= mapping-03 >=20 > 7. AUDIO-RENDERING-ID =E2=80=93 If the notion of an audio ren= dering tag is >=20 > adopted, this would be needed. It is an ID provided by the consumer t= o the >=20 > provider. The provider uses the tag to associate an audio stream with= a video >=20 > stream. >=20 > RE; suggest to take this out at the moment until we agree i= f needed and how to map. > EBE> I assume that matching RTCP SDES CNAME is still the preferred mechani= sms for syncing audio and video for lip-sync (as defined in RFC3550). When w= e discussed audio tags last interim it as was presented as a tool for improv= ing directional audio. > =20 >=20 > Clearly this doesn=E2=80=99t cover all the data model issues, but it=E2=80= =99s a start. >=20 > =20 >=20 > Thanks, >=20 > Andy and Allyn >=20 > =20 > =20 >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue >=20 > =20 --Apple-Mail-1417C101-7C5C-4B5B-A306-C6B511C851D7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi Roni,

While what you say seems to be applicable here to CLUE, a couple of t= hings spring to mind:

- it's not clear that we'll b= e declaring SSRC values in SDP as webrtc dies, so being able to specify imag= eattr there might not be of use

- even if we were, t= here's no obvious defined SSRC <-> media capture mapping being conside= red. Specifically, at offer-time the provider wouldn't know which SSRCs were= to be used for which captures and so wouldn't be able to determine which im= ageattr values to assign with which SSRC values.

I c= an understand how what you describe works fine for webrtc - did you have a s= cheme in mind for tackling the above entwined issues (especially the second o= ne) ?

Regards,

Andy
<= div>

On 1 Aug 2012, at 02:25, "Roni Even" <ron.even.tlv@gmail.com> wrote:

<= /div>

Andy,

The image attribute provides a better sol= ution  to allow the consumer to ask for a preferred image size which is= not only the aspect ratio but the resolution and pixel aspect ratio.  = It can be specified per SSRC http://tools.ietf.org/html/draft-lennox-= mmusic-sdp-source-selection-03

The consensus in RTCweb was to use this soluti= on  based on http://tools.ietf.org/html/draft-alvestrand-rtcweb-resolu= tion-00

 

Roni

 

From:= Andy Pepperell [mailto:apeppere@gmail.com]
Sen= t: 01 August, 2012 1:41 AM
To: Allyn Romanow (allyn)
Cc:= Espen Berger (espeberg); Roni Even; CLUE
Subject: Re: [clue] a= few issues on data model draft

=  

&= gt;>>Currently it is not possible to tell whether a remote video sourc= e is natively 4:3 or 16:9, for instance.
>>>If we have this, the= re might usefully be a "PREFERRED-ASPECT-RATIO" in the consumer's stream sel= ection message as part of the  (e.g. in "<stream-description> / &= lt;encoding>").

>>Roni: RE: No need, first of all it does no= t work with switched capture that may have different aspect ratios. Also thi= s is available in the SDP as well as a way for receiver to ask for specific r= atio using the SDP image attribute.

>AR =E2=80=93 I=E2=80=99ll let= Andy respond to this

Many apologies for not doing so until now...
Roni, I think you're right in that at least the native aspect ratio as p= otentially expressed in a provider's capture advertisement wouldn't work for= the switched capture case (or at least wouldn't work all the time - for the= endpoint case where the switched capture was a dynamic choice between one o= f the "real" cameras' image then it would be possible (and straightforward) t= o attach the same native aspect ratio to the switched capture as was applica= ble to the non-switched captures). Even if it were impossible to attach a "n= ative aspect ratio" to the switched case, to my mind this doesn't necessaril= y take away from the validity in this scenario of the consumer supplying a "= preferred aspect ratio" in its stream selection message.

re: use of "= imageattr" in the SDP, it's definitely pertinent here; potentially this has s= ome issues in relation to CLUE:

- it would have to be applied on a pe= r m line basis (excluding payload type differences) rather than per capture -= within CLUE there would be a need (or at least use) of the aspect ratio spe= cification being more fine-grained and separately specifiable per capture (t= his may depend in part on how we eventually choose to manage main vs slides v= ideo in terms of RTP session association though).

- by being in SDP, i= t's presumably the case that to correctly signal to the consumer when, say, a= 4:3 presentation source had been connected would require an additional offe= r / answer cycle (and similarly if that source were to be disconnected and a= new 16:9 source attached) - this seems slightly less lightweight than the e= quivalent operation would be if its scope were restricted to just the CLUE p= rovider capture advertisement. As a side point, it also seems more heavyweig= ht than SIP without the use of imageattr too, where presumably the only impa= ct of connecting such a presentation source would be a BFCP exchange.
I'm happy to own up here to not having seen this attribute being present in= devices' SDP, so if any of the above are inaccurate due to my ignorance on t= his, I apologise. It would certainly be interesting to get some sort of pict= ure of the adoption of "imageattr" within the vendor community - I don't rec= all seeing this in use, but most of my exposure has been to systems not nece= ssarily running recent software versions. Obviously if the already-defined "= imageattr" does all we'd like within CLUE, then we should use this already-d= efined scheme.

Regards,

Andy

On Sun, Jul 29, 2012 at 4:58 AM, Allyn Romanow (allyn) <= allyn@cisco.com>= wrote:

Hi Espen,<= /span>

Thanks for your comme= nts-

Please see belo= w-

Also inline in res= ponse to your inline J

From: Espen Berger (espeberg)
Sent: Monday, July 23, 2= 012 8:27 AM
To: Allyn Romanow (allyn); Roni Even; 'CLUE'


Subject: RE: [clue] a few= issues on data model draft

 

I have two que= stions to the data model draft.

 

The first questions is related to naming di= fferences between the CLUE framework and the CLUE data model. Some examples o= f differences. the framework uses Description and the data model uses captur= e-scene-text, the framework uses capture and the data model uses capture-des= cription . Isn=E2=80=99t it natural that both documents share the same vocab= ulary?

AR =E2= =80=93 Christian also brought this up.   I believe that the docume= nts will not have the same vocabulary =E2=80=93 but the concepts are the sam= e.     The framework was written first and it=E2=80=99s g= oal is to describe things as clearly as possible (we=E2=80=99re not done wit= h that=E2=80=A6). The data model is more formal and the language there is no= t casual. It was developed after the framework, so it sort of distils the id= eas in the framework. 

 

If t= here is a discrepancy of meaning, that is an issue and we should definitely s= ort it out. But in terms of language, I think it=E2=80=99s fine to either le= ave it different or  change the framework at some point to be more in k= eeping with the data model.. but I think it=E2=80=99s a good idea to do that= later when the data model is about agreed upon.    &nbs= p;            =

 

I=E2=80=99ve put this on the list for d= iscussion at the IETF meeting on Weds.      &n= bsp;            =             &nbs= p;            &n= bsp;             = ;            &nb= sp;            &= nbsp;            = ;            &nb= sp;           =

 <= /span>

The se= cond questions is related to the concept of doing a data model as the basis f= or both advertisement and configuration messages. Playing around with some X= ML examples messages it=E2=80=99s not obvious that the two messages types sh= are a common data model. I do see similarities between the initial advertise= ment, the current active configuration and the advantages of be able to desc= ribe the state of a running CLUE system. Assume this will be sorted out when= we look at the details of how to do configuration in CLUE.  

 

AR - Okay, this is int= eresting. Guess I=E2=80=99ll have to wait to see more specifically what issu= es arise.

 

Additional comments inline.

 

-Espen

 

 

From: clue-bounces@ietf.org= [mailto:clue-bounces@ietf.org] = On Behalf Of Allyn Romanow (allyn)


Sent: 18. juli 2012 23:00
To: Roni Even; 'C= LUE'
Subject: Re: [clue] a few issues on data model draft

 

Hi Roni,

<= p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-alt= :auto">Sure, these are easy to add-

thanks

 

From: Roni Even [mailto= :ron.even.tlv@gmail.com]

Sent: Wednesday, July 18, 2012 2:56 PM
To:= Allyn Romanow (allyn); 'CLUE'
Subject: RE: [clue] a few issue= s on data model draft

 

Hi,

Reviewed the draft, inline for your question (B= TW: not all the new attributes here are in BOLD for example captureID)

 

Other comments

 

1.       Need t= o add axis of capture to the media capture (now in the framework)

2.       The capture scene text and language should be sets of (text, lan= guage), I think is not the current structure

 

Thanks

Roni

 

From: clue-bounces@ietf.org [mailto:clue-bounc= es@ietf.org] On Behalf Of Allyn Romanow (allyn)=
Sent: 18 July, 2012 3:22 AM
To: CLUE (clue@ietf.org= )
Subject: [clue] a few issues on data model draft

 

Folks,

There are several issues related= to the data model that we=E2=80=99d like us to consider. These are things t= hat are not exactly the same as in the framework, to a lesser or greater ext= ent. They were brought up during the data model presentation at the interim m= eeting. I wonder if we could work on resolving them?

List based on draft-rom= anow-clue-data-model-01

<= span style=3D"font-family:"Courier New"">1.  Any problem with using media-type for capture attribute as described i= n the draft?

RE: OK


EBE> Supported, since its allow us to join the audio and video enc= odings into a single list of encodings.

2.=   Any problem with using content-type for capture attrib= ute as described in the draft?

            =     RE: I did not see any difference from the framework in wh= ich case I am OK.

 &nbs= p;             E= BE> The framework use the =E2=80=98content=E2=80=99 name and the data mod= el the =E2=80=98content-type=E2=80=99 name. Why not use the same name?  = ;

AR- as above<= /o:p>

3.  <= span style=3D"font-family:"Courier New"">DERIVED for capture attri= bute- Should we have a variable called something like DERIVED, that takes va= rious values, one of which is composed. That would mean that if DERIVED is n= ot =3Dcomposed, that the capture is not composed, and if it =3Dcomposed then= it is. I don=E2=80=99t have another descriptor to propose now, but there co= uld be others either now or later.

Why this chang= e from the framework? I think it is more general than composed Boolean, yet s= emantically similar.

This does not prevent us fro= m having qualifiers to describe composed, to help  distinguish between d= ifferent composed captures, as has  been discussed. Also, it needs to b= e possible to have multiple values for =E2=80=9CDERIVED=E2=80=9D, that is th= e values should not be mutually exclusive.

<= p class=3D"MsoNormal">         =        RE:  I am OK if this is for future= extension but am not sure about the structure  the high level derived w= hich has Compose and future something (not sure what). The composed has a va= lue (true, false) and child elements for extensions . Is this the proposed s= tructure?

EBE> I like the= idea of describing the origin of the capture with an attribute that is more= extensible than a Boolean. What about creating enumerated values for the tw= o origins we are currently discussing. We have =E2=80=98composed=E2=80=99 (c= omposed=3Dtrue) meaning that the media has been changed in some way and orig= inal (composed=3Dfalse).

= 4.  Leave switched a= s a Boolean as in framework. The proposal in the draft seems infeasible =E2=80= =93 we don=E2=80=99t want CLUE  to have to include all the ways in whic= h products might want to implement switching. It would be better to make thi= s more general, but we have no suggestion for it at present- it does not rea= lly match the meaning of a derived capture.

         = ;       RE: I think that if we have the extens= ion for composed as I outlined above we can have similar here.

5.  <= span style=3D"font-family:"Courier New"">As part of the capture de= scription, should we have a parameter NATIVE-ASPECT-RATIO, which indicates t= he aspect ratio for the capture if there is one, such as 4:3 for a video cam= era? The reason is that it can help rendering.



Currently it is not possible to tell whether a re= mote video source is natively 4:3 or 16:9, for instance. If we have this, th= ere might usefully be a "PREFERRED-ASPECT-RATIO" in the consumer's stream se= lection message as part of the  (e.g. in "<stream-description> / &= lt;encoding>").

 &nb= sp;            &= nbsp; RE: No need, first of all it does not work with switched capture that m= ay have different aspect ratios. Also this is available in the SDP as well a= s a way for receiver to ask for specific ratio using the SDP image attribute= .

EBE> The image attribut= e (RFC6236) document talks about image resolution and picture aspect ratio, a= nd how they relates to codec specific parameters like h264 max-fs and max-mb= ps.  An attribute can have a single value, a list of values or a range.=

6.  &= nbsp;Multiplex ID= =E2=80=93 Value sent by consumer in its stream selection message with the e= ncoding id and capture id. This is the mechanism by which the consumer tells= the provider which multiplex id to generate that stream with, so that the c= onsumer can demultiplex the stream correctly when receiving it. =

This is the link between RTP and CLUE a= s discussed in draft-lennox-clue-rtp-usage.

     Think should probably be re-named.

 &n= bsp;            = RE: I do not see the need the mapping is to the capture ID which is a numer= ic value. See http://tools.ietf.org/html/draf= t-even-clue-rtp-mapping-03 =

          &n= bsp;7.  AUDIO-RENDERING-ID =E2=80=93 &= nbsp;If the notion of an audio rendering tag is

    &nbs= p;adopted, this would be needed. It is an ID provided by the consumer to the=

     provider. The provider uses the tag to associate a= n audio stream with a video

    stream.

      &= nbsp;         RE; suggest to take th= is out at the moment until we agree if needed and how to map.

=

EBE> I assume that matching RTCP SDES C= NAME is still the preferred mechanisms for syncing audio and video for lip-s= ync (as defined in RFC3550). When we discussed audio tags last interim it as= was presented as a tool for improving directional audio.

 

Clearly this doesn=E2=80=99t cover all= the data model issues, but it=E2=80=99s a start.

 

Thanks,=

Andy and Al= lyn

 

&n= bsp;


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

<= p class=3D"MsoNormal"> 

<= /html>= --Apple-Mail-1417C101-7C5C-4B5B-A306-C6B511C851D7-- From apeppere@gmail.com Wed Aug 1 06:53: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 7C86421F8DAD for ; Wed, 1 Aug 2012 06:53:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.202 X-Spam-Level: X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, 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 K4gUF8MmUaiR for ; Wed, 1 Aug 2012 06:53:39 -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 BB66B21F8DAC for ; Wed, 1 Aug 2012 06:53:38 -0700 (PDT) Received: by weyu54 with SMTP id u54so5779301wey.31 for ; Wed, 01 Aug 2012 06:53:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; bh=7v/z5LxAAFE9xVGFX2gAhIHfFxHzZ/4buWyvnYNJOgc=; b=jYtxf5uNCg3IoQPB9ImCV5VBMha7lujitSK6ws3JngCZdmN4USB4AF03rn+fT4VVZ+ 4ZMRCChk1ytWdNjo6LLVBXqGE94wvg3r9vgMJ9PzpGLvrwlW/6stUvewIYW2SYCAMEzX /wt9w7sr50/YsSMGAN5IWDjATrAlW5nk9BPSgJHdzCVKK9Gd2X1udnjb29tLKjfwRsU+ 2rYQhzA0o14SdKInBOhas0e6pxT1ORzyjXwgAk+maZEnmNRaECRLJWIo6htfTfIa5E7Y hV8Zq6oQ8gVLgH8uXxp49W996ze5XoOMbIec6/D2nPVL4IjFBPxx7jjPvKYabXhxyWZB bWcw== Received: by 10.180.20.11 with SMTP id j11mr10478687wie.12.1343829217858; Wed, 01 Aug 2012 06:53:37 -0700 (PDT) Received: from [10.5.220.76] ([212.183.140.19]) by mx.google.com with ESMTPS id ex20sm8897636wid.7.2012.08.01.06.53.18 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 01 Aug 2012 06:53:36 -0700 (PDT) References: <003e01cd6f84$86f63120$94e29360$@gmail.com> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-046B141C-913B-45F6-9E69-7B24DD8774F6 Message-Id: <36033C16-D22C-4C9C-9B52-EAD2FF9F75AF@gmail.com> X-Mailer: iPhone Mail (9B206) From: Andrew Pepperell Date: Wed, 1 Aug 2012 14:53:10 +0100 To: Andrew Pepperell Cc: CLUE Subject: Re: [clue] a few issues on data model draft 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, 01 Aug 2012 13:53:40 -0000 --Apple-Mail-046B141C-913B-45F6-9E69-7B24DD8774F6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thanks to those of you who pointed out my totally non-Freudian slip - "webrt= c dies" was meant to be "webrtc does" (!). Maybe I can blame Apple's auto-co= rrect which also decided that "above mentioned" was better said as "entwined= ". Andy On 1 Aug 2012, at 14:05, Andrew Pepperell wrote: > Hi Roni, >=20 > While what you say seems to be applicable here to CLUE, a couple of things= spring to mind: >=20 > - it's not clear that we'll be declaring SSRC values in SDP as webrtc dies= , so being able to specify imageattr there might not be of use >=20 > - even if we were, there's no obvious defined SSRC <-> media capture mappi= ng being considered. Specifically, at offer-time the provider wouldn't know w= hich SSRCs were to be used for which captures and so wouldn't be able to det= ermine which imageattr values to assign with which SSRC values. >=20 > I can understand how what you describe works fine for webrtc - did you hav= e a scheme in mind for tackling the above entwined issues (especially the se= cond one) ? >=20 > Regards, >=20 > Andy >=20 >=20 > On 1 Aug 2012, at 02:25, "Roni Even" wrote: >=20 >> Andy, >> The image attribute provides a better solution to allow the consumer to a= sk for a preferred image size which is not only the aspect ratio but the res= olution and pixel aspect ratio. It can be specified per SSRC http://tools.i= etf.org/html/draft-lennox-mmusic-sdp-source-selection-03 >> The consensus in RTCweb was to use this solution based on http://tools.i= etf.org/html/draft-alvestrand-rtcweb-resolution-00 >> =20 >> Roni >> =20 >> From: Andy Pepperell [mailto:apeppere@gmail.com]=20 >> Sent: 01 August, 2012 1:41 AM >> To: Allyn Romanow (allyn) >> Cc: Espen Berger (espeberg); Roni Even; CLUE >> Subject: Re: [clue] a few issues on data model draft >> =20 >> >>>Currently it is not possible to tell whether a remote video source is n= atively 4:3 or 16:9, for instance. >> >>>If we have this, there might usefully be a "PREFERRED-ASPECT-RATIO" in= the consumer's stream selection message as part of the (e.g. in " / "). >>=20 >> >>Roni: RE: No need, first of all it does not work with switched capture t= hat may have different aspect ratios. Also this is available in the SDP as w= ell as a way for receiver to ask for specific ratio using the SDP image attr= ibute. >>=20 >> >AR =E2=80=93 I=E2=80=99ll let Andy respond to this >>=20 >> Many apologies for not doing so until now... >>=20 >> Roni, I think you're right in that at least the native aspect ratio as po= tentially expressed in a provider's capture advertisement wouldn't work for t= he switched capture case (or at least wouldn't work all the time - for the e= ndpoint case where the switched capture was a dynamic choice between one of t= he "real" cameras' image then it would be possible (and straightforward) to a= ttach the same native aspect ratio to the switched capture as was applicable= to the non-switched captures). Even if it were impossible to attach a "nati= ve aspect ratio" to the switched case, to my mind this doesn't necessarily t= ake away from the validity in this scenario of the consumer supplying a "pre= ferred aspect ratio" in its stream selection message. >>=20 >> re: use of "imageattr" in the SDP, it's definitely pertinent here; potent= ially this has some issues in relation to CLUE: >>=20 >> - it would have to be applied on a per m line basis (excluding payload ty= pe differences) rather than per capture - within CLUE there would be a need (= or at least use) of the aspect ratio specification being more fine-grained a= nd separately specifiable per capture (this may depend in part on how we eve= ntually choose to manage main vs slides video in terms of RTP session associ= ation though). >>=20 >> - by being in SDP, it's presumably the case that to correctly signal to t= he consumer when, say, a 4:3 presentation source had been connected would re= quire an additional offer / answer cycle (and similarly if that source were t= o be disconnected and a new 16:9 source attached) - this seems slightly less= lightweight than the equivalent operation would be if its scope were restri= cted to just the CLUE provider capture advertisement. As a side point, it al= so seems more heavyweight than SIP without the use of imageattr too, where p= resumably the only impact of connecting such a presentation source would be a= BFCP exchange. >>=20 >> I'm happy to own up here to not having seen this attribute being present i= n devices' SDP, so if any of the above are inaccurate due to my ignorance on= this, I apologise. It would certainly be interesting to get some sort of pi= cture of the adoption of "imageattr" within the vendor community - I don't r= ecall seeing this in use, but most of my exposure has been to systems not ne= cessarily running recent software versions. Obviously if the already-defined= "imageattr" does all we'd like within CLUE, then we should use this already= -defined scheme. >>=20 >> Regards, >>=20 >> Andy >>=20 >>=20 >> On Sun, Jul 29, 2012 at 4:58 AM, Allyn Romanow (allyn) w= rote: >> Hi Espen, >> Thanks for your comments- >> Please see below- >> Also inline in response to your inline J >> =20 >> From: Espen Berger (espeberg)=20 >> Sent: Monday, July 23, 2012 8:27 AM >> To: Allyn Romanow (allyn); Roni Even; 'CLUE' >>=20 >> Subject: RE: [clue] a few issues on data model draft >> =20 >> I have two questions to the data model draft. >> =20 >> The first questions is related to naming differences between the CLUE fra= mework and the CLUE data model. Some examples of differences. the framework u= ses Description and the data model uses capture-scene-text, the framework us= es capture and the data model uses capture-description . Isn=E2=80=99t it na= tural that both documents share the same vocabulary? >> =20 >> AR =E2=80=93 Christian also brought this up. I believe that the documen= ts will not have the same vocabulary =E2=80=93 but the concepts are the same= . The framework was written first and it=E2=80=99s goal is to describe t= hings as clearly as possible (we=E2=80=99re not done with that=E2=80=A6). Th= e data model is more formal and the language there is not casual. It was dev= eloped after the framework, so it sort of distils the ideas in the framework= .=20 >> =20 >> If there is a discrepancy of meaning, that is an issue and we should defi= nitely sort it out. But in terms of language, I think it=E2=80=99s fine to e= ither leave it different or change the framework at some point to be more i= n keeping with the data model.. but I think it=E2=80=99s a good idea to do t= hat later when the data model is about agreed upon. =20 >> =20 >> I=E2=80=99ve put this on the list for discussion at the IETF meeting on W= eds. = =20 >> =20 >> The second questions is related to the concept of doing a data model as t= he basis for both advertisement and configuration messages. Playing around w= ith some XML examples messages it=E2=80=99s not obvious that the two message= s types share a common data model. I do see similarities between the initial= advertisement, the current active configuration and the advantages of be ab= le to describe the state of a running CLUE system. Assume this will be sorte= d out when we look at the details of how to do configuration in CLUE. =20 >> =20 --Apple-Mail-046B141C-913B-45F6-9E69-7B24DD8774F6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Thanks to those of you who= pointed out my totally non-Freudian slip - "webrtc dies" was meant to be "w= ebrtc does" (!). Maybe I can blame Apple's auto-correct which also decided t= hat "above mentioned" was better said as "entwined".

Andy

On 1 Aug 2012, at 14:05, Andrew Pepperell <apeppere@gmail.com> wrote:

Hi Roni,

Wh= ile what you say seems to be applicable here to CLUE, a couple of things spr= ing to mind:

- it's not clear that we'll be declari= ng SSRC values in SDP as webrtc dies, so being able to specify imageattr the= re might not be of use

- even if we were, there's n= o obvious defined SSRC <-> media capture mapping being considered. Spe= cifically, at offer-time the provider wouldn't know which SSRCs were to be u= sed for which captures and so wouldn't be able to determine which imageattr v= alues to assign with which SSRC values.

I can under= stand how what you describe works fine for webrtc - did you have a scheme in= mind for tackling the above entwined issues (especially the second one) ?

Regards,

Andy

On 1 Aug 2012, at 02:25, "Roni Even" <ron.even.tlv@gmail.com> wrote:

Andy,

The image attribute provides a better sol= ution  to allow the consumer to ask for a preferred image size which is= not only the aspect ratio but the resolution and pixel aspect ratio.  = It can be specified per SSRC http://tools.ietf.org/html/draft-lennox-= mmusic-sdp-source-selection-03

The consensus in RTCweb was to use this soluti= on  based on http://tools.ietf.org/html/draft-alvestrand-rtcweb-resolu= tion-00

 

Roni

 

From:= Andy Pepperell [mailto:apeppere@gmail.com]
Sen= t: 01 August, 2012 1:41 AM
To: Allyn Romanow (allyn)
Cc:= Espen Berger (espeberg); Roni Even; CLUE
Subject: Re: [clue] a= few issues on data model draft

=  

&= gt;>>Currently it is not possible to tell whether a remote video sourc= e is natively 4:3 or 16:9, for instance.
>>>If we have this, the= re might usefully be a "PREFERRED-ASPECT-RATIO" in the consumer's stream sel= ection message as part of the  (e.g. in "<stream-description> / &= lt;encoding>").

>>Roni: RE: No need, first of all it does no= t work with switched capture that may have different aspect ratios. Also thi= s is available in the SDP as well as a way for receiver to ask for specific r= atio using the SDP image attribute.

>AR =E2=80=93 I=E2=80=99ll let= Andy respond to this

Many apologies for not doing so until now...
Roni, I think you're right in that at least the native aspect ratio as p= otentially expressed in a provider's capture advertisement wouldn't work for= the switched capture case (or at least wouldn't work all the time - for the= endpoint case where the switched capture was a dynamic choice between one o= f the "real" cameras' image then it would be possible (and straightforward) t= o attach the same native aspect ratio to the switched capture as was applica= ble to the non-switched captures). Even if it were impossible to attach a "n= ative aspect ratio" to the switched case, to my mind this doesn't necessaril= y take away from the validity in this scenario of the consumer supplying a "= preferred aspect ratio" in its stream selection message.

re: use of "= imageattr" in the SDP, it's definitely pertinent here; potentially this has s= ome issues in relation to CLUE:

- it would have to be applied on a pe= r m line basis (excluding payload type differences) rather than per capture -= within CLUE there would be a need (or at least use) of the aspect ratio spe= cification being more fine-grained and separately specifiable per capture (t= his may depend in part on how we eventually choose to manage main vs slides v= ideo in terms of RTP session association though).

- by being in SDP, i= t's presumably the case that to correctly signal to the consumer when, say, a= 4:3 presentation source had been connected would require an additional offe= r / answer cycle (and similarly if that source were to be disconnected and a= new 16:9 source attached) - this seems slightly less lightweight than the e= quivalent operation would be if its scope were restricted to just the CLUE p= rovider capture advertisement. As a side point, it also seems more heavyweig= ht than SIP without the use of imageattr too, where presumably the only impa= ct of connecting such a presentation source would be a BFCP exchange.
I'm happy to own up here to not having seen this attribute being present in= devices' SDP, so if any of the above are inaccurate due to my ignorance on t= his, I apologise. It would certainly be interesting to get some sort of pict= ure of the adoption of "imageattr" within the vendor community - I don't rec= all seeing this in use, but most of my exposure has been to systems not nece= ssarily running recent software versions. Obviously if the already-defined "= imageattr" does all we'd like within CLUE, then we should use this already-d= efined scheme.

Regards,

Andy

On Sun, Jul 29, 2012 at 4:58 AM, Allyn Romanow (allyn) <= allyn@cisco.com>= wrote:

Hi Espen,<= /span>

Thanks for your comme= nts-

Please see belo= w-

Also inline in res= ponse to your inline J

From: Espen Berger (espeberg)
Sent: Monday, July 23, 2= 012 8:27 AM
To: Allyn Romanow (allyn); Roni Even; 'CLUE'


Subject: RE: [clue] a few= issues on data model draft

 

I have two que= stions to the data model draft.

 

The first questions is related to naming di= fferences between the CLUE framework and the CLUE data model. Some examples o= f differences. the framework uses Description and the data model uses captur= e-scene-text, the framework uses capture and the data model uses capture-des= cription . Isn=E2=80=99t it natural that both documents share the same vocab= ulary?

AR =E2= =80=93 Christian also brought this up.   I believe that the docume= nts will not have the same vocabulary =E2=80=93 but the concepts are the sam= e.     The framework was written first and it=E2=80=99s g= oal is to describe things as clearly as possible (we=E2=80=99re not done wit= h that=E2=80=A6). The data model is more formal and the language there is no= t casual. It was developed after the framework, so it sort of distils the id= eas in the framework. 

 

If t= here is a discrepancy of meaning, that is an issue and we should definitely s= ort it out. But in terms of language, I think it=E2=80=99s fine to either le= ave it different or  change the framework at some point to be more in k= eeping with the data model.. but I think it=E2=80=99s a good idea to do that= later when the data model is about agreed upon.    &nbs= p;            =

 

I=E2=80=99ve put this on the list for d= iscussion at the IETF meeting on Weds.      &n= bsp;            =             &nbs= p;            &n= bsp;             = ;            &nb= sp;            &= nbsp;            = ;            &nb= sp;           =

 <= /span>

The se= cond questions is related to the concept of doing a data model as the basis f= or both advertisement and configuration messages. Playing around with some X= ML examples messages it=E2=80=99s not obvious that the two messages types sh= are a common data model. I do see similarities between the initial advertise= ment, the current active configuration and the advantages of be able to desc= ribe the state of a running CLUE system. Assume this will be sorted out when= we look at the details of how to do configuration in CLUE.  

 

= --Apple-Mail-046B141C-913B-45F6-9E69-7B24DD8774F6-- From ron.even.tlv@gmail.com Wed Aug 1 07:44: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 1EABE21F8861 for ; Wed, 1 Aug 2012 07:44:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xbmwZlo+BVJB for ; Wed, 1 Aug 2012 07:44:14 -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 7385A21F885B for ; Wed, 1 Aug 2012 07:44:14 -0700 (PDT) Received: by pbbjt11 with SMTP id jt11so1236340pbb.31 for ; Wed, 01 Aug 2012 07:44:14 -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:x-mailer:thread-index:content-language; bh=+tY+klrJbHUQ1Pl/Cm5AXyEpjaNbY8ycsftzx24gIgo=; b=i1w7ppmvEgMv9voQhK3hLUt60D1UnCRkkO+kCr0pNG/MCAaM0ydEgEcPKwoEcH+uKb 0/KmVAGkNoYciVZ2I33JzUhwXXqyJKjZLK9VKsUMJ5k7m57we2/bsNtEuwRRqjwZ3H4b N/jhUEG0GBuaDgMoEhyBdPLMLyWnAf1pGTQbJalNcdNn9ePZhWA1iwdMD4u8D8l3+jG0 oVNpdlL7FNZgPv8vWE9Fqt6V4v0HU7QQQHcNilb7CwU0L5WN/WlDbKdyb7cxPreCI+NQ aaKV/C/G/PMONJwOnnSPfSW0qRSgoxjl0b0zHMgIyJaZpafDaMNYlAyYiHj2OXtc3/ta a95Q== Received: by 10.68.229.2 with SMTP id sm2mr52184562pbc.57.1343832254117; Wed, 01 Aug 2012 07:44:14 -0700 (PDT) Received: from RoniE ([2001:df8:0:64:95c4:dadd:4dfc:24cf]) by mx.google.com with ESMTPS id qp9sm2729078pbc.9.2012.08.01.07.44.11 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 01 Aug 2012 07:44:13 -0700 (PDT) From: "Roni Even" To: "'Andrew Pepperell'" References: <003e01cd6f84$86f63120$94e29360$@gmail.com> <36033C16-D22C-4C9C-9B52-EAD2FF9F75AF@gmail.com> In-Reply-To: <36033C16-D22C-4C9C-9B52-EAD2FF9F75AF@gmail.com> Date: Wed, 1 Aug 2012 17:42:52 +0200 Message-ID: <003b01cd6ffc$59896270$0c9c2750$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_003C_01CD700D.1D142E40" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKWYUEgNa6IsauA+88Ek8WS63kd0gI/9J3nAWavt+kB2Sp3NAHl9sadlXgF8iA= Content-Language: en-us Cc: 'CLUE' Subject: Re: [clue] a few issues on data model draft 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, 01 Aug 2012 14:44:16 -0000 This is a multipart message in MIME format. ------=_NextPart_000_003C_01CD700D.1D142E40 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Andy, The SSRC will be known even if not declared in the SDP offer since it = will conveyed in any mapping mechanism we are discussing now. (Static in = SDP and Dynamic in RTP header extension)=20 =20 Note that in any case the consumer cannot ask ahead for a preferred = value that will be known by all providers in the MCU case since the = media capture is from the MCU and the consumer will need to request it = when the switch occurs and he sees a new SSRC. =20 =20 Roni =20 From: Andrew Pepperell [mailto:apeppere@gmail.com]=20 Sent: 01 August, 2012 3:53 PM To: Andrew Pepperell Cc: Roni Even; Allyn Romanow (allyn); Espen Berger (espeberg); CLUE Subject: Re: [clue] a few issues on data model draft =20 Thanks to those of you who pointed out my totally non-Freudian slip - = "webrtc dies" was meant to be "webrtc does" (!). Maybe I can blame = Apple's auto-correct which also decided that "above mentioned" was = better said as "entwined". =20 Andy On 1 Aug 2012, at 14:05, Andrew Pepperell wrote: Hi Roni, =20 While what you say seems to be applicable here to CLUE, a couple of = things spring to mind: =20 - it's not clear that we'll be declaring SSRC values in SDP as webrtc = dies, so being able to specify imageattr there might not be of use =20 - even if we were, there's no obvious defined SSRC <-> media capture = mapping being considered. Specifically, at offer-time the provider = wouldn't know which SSRCs were to be used for which captures and so = wouldn't be able to determine which imageattr values to assign with = which SSRC values. =20 I can understand how what you describe works fine for webrtc - did you = have a scheme in mind for tackling the above entwined issues (especially = the second one) ? =20 Regards, =20 Andy On 1 Aug 2012, at 02:25, "Roni Even" wrote: Andy, The image attribute provides a better solution to allow the consumer to = ask for a preferred image size which is not only the aspect ratio but = the resolution and pixel aspect ratio. It can be specified per SSRC = http://tools.ietf.org/html/draft-lennox-mmusic-sdp-source-selection-03=20 The consensus in RTCweb was to use this solution based on = http://tools.ietf.org/html/draft-alvestrand-rtcweb-resolution-00=20 =20 Roni =20 From: Andy Pepperell [mailto:apeppere@gmail.com]=20 Sent: 01 August, 2012 1:41 AM To: Allyn Romanow (allyn) Cc: Espen Berger (espeberg); Roni Even; CLUE Subject: Re: [clue] a few issues on data model draft =20 >>>Currently it is not possible to tell whether a remote video source is = natively 4:3 or 16:9, for instance. >>>If we have this, there might usefully be a "PREFERRED-ASPECT-RATIO" = in the consumer's stream selection message as part of the (e.g. in = " / "). >>Roni: RE: No need, first of all it does not work with switched capture = that may have different aspect ratios. Also this is available in the SDP = as well as a way for receiver to ask for specific ratio using the SDP = image attribute. >AR =E2=80=93 I=E2=80=99ll let Andy respond to this Many apologies for not doing so until now... Roni, I think you're right in that at least the native aspect ratio as = potentially expressed in a provider's capture advertisement wouldn't = work for the switched capture case (or at least wouldn't work all the = time - for the endpoint case where the switched capture was a dynamic = choice between one of the "real" cameras' image then it would be = possible (and straightforward) to attach the same native aspect ratio to = the switched capture as was applicable to the non-switched captures). = Even if it were impossible to attach a "native aspect ratio" to the = switched case, to my mind this doesn't necessarily take away from the = validity in this scenario of the consumer supplying a "preferred aspect = ratio" in its stream selection message. re: use of "imageattr" in the SDP, it's definitely pertinent here; = potentially this has some issues in relation to CLUE: - it would have to be applied on a per m line basis (excluding payload = type differences) rather than per capture - within CLUE there would be a = need (or at least use) of the aspect ratio specification being more = fine-grained and separately specifiable per capture (this may depend in = part on how we eventually choose to manage main vs slides video in terms = of RTP session association though). - by being in SDP, it's presumably the case that to correctly signal to = the consumer when, say, a 4:3 presentation source had been connected = would require an additional offer / answer cycle (and similarly if that = source were to be disconnected and a new 16:9 source attached) - this = seems slightly less lightweight than the equivalent operation would be = if its scope were restricted to just the CLUE provider capture = advertisement. As a side point, it also seems more heavyweight than SIP = without the use of imageattr too, where presumably the only impact of = connecting such a presentation source would be a BFCP exchange. I'm happy to own up here to not having seen this attribute being present = in devices' SDP, so if any of the above are inaccurate due to my = ignorance on this, I apologise. It would certainly be interesting to get = some sort of picture of the adoption of "imageattr" within the vendor = community - I don't recall seeing this in use, but most of my exposure = has been to systems not necessarily running recent software versions. = Obviously if the already-defined "imageattr" does all we'd like within = CLUE, then we should use this already-defined scheme. Regards, Andy On Sun, Jul 29, 2012 at 4:58 AM, Allyn Romanow (allyn) = wrote: Hi Espen, Thanks for your comments-=20 Please see below- Also inline in response to your inline J =20 From: Espen Berger (espeberg)=20 Sent: Monday, July 23, 2012 8:27 AM To: Allyn Romanow (allyn); Roni Even; 'CLUE' Subject: RE: [clue] a few issues on data model draft =20 I have two questions to the data model draft.=20 =20 The first questions is related to naming differences between the CLUE = framework and the CLUE data model. Some examples of differences. the = framework uses Description and the data model uses capture-scene-text, = the framework uses capture and the data model uses capture-description . = Isn=E2=80=99t it natural that both documents share the same vocabulary?=20 =20 AR =E2=80=93 Christian also brought this up. I believe that the = documents will not have the same vocabulary =E2=80=93 but the concepts = are the same. The framework was written first and it=E2=80=99s goal = is to describe things as clearly as possible (we=E2=80=99re not done = with that=E2=80=A6). The data model is more formal and the language = there is not casual. It was developed after the framework, so it sort of = distils the ideas in the framework. =20 =20 If there is a discrepancy of meaning, that is an issue and we should = definitely sort it out. But in terms of language, I think it=E2=80=99s = fine to either leave it different or change the framework at some point = to be more in keeping with the data model.. but I think it=E2=80=99s a = good idea to do that later when the data model is about agreed upon. = =20 =20 I=E2=80=99ve put this on the list for discussion at the IETF meeting on = Weds. = =20 =20 The second questions is related to the concept of doing a data model as = the basis for both advertisement and configuration messages. Playing = around with some XML examples messages it=E2=80=99s not obvious that the = two messages types share a common data model. I do see similarities = between the initial advertisement, the current active configuration and = the advantages of be able to describe the state of a running CLUE = system. Assume this will be sorted out when we look at the details of = how to do configuration in CLUE. =20 =20 ------=_NextPart_000_003C_01CD700D.1D142E40 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Andy,

The SSRC will be known even if not declared in the SDP offer since it = will conveyed in any mapping mechanism we are discussing now. (Static in = SDP and Dynamic in RTP header extension)

 

Note that in any case the consumer cannot ask ahead for a preferred = value that will be known by all providers in the MCU case =C2=A0since = the media capture is from the MCU and the consumer will need to request = it when the switch occurs and he sees a new = SSRC.

 

 

Roni

 

From:= = Andrew Pepperell [mailto:apeppere@gmail.com]
Sent: 01 August, = 2012 3:53 PM
To: Andrew Pepperell
Cc: Roni Even; = Allyn Romanow (allyn); Espen Berger (espeberg); CLUE
Subject: = Re: [clue] a few issues on data model = draft

 

Thanks = to those of you who pointed out my totally non-Freudian slip - = "webrtc dies" was meant to be "webrtc does" (!). = Maybe I can blame Apple's auto-correct which also decided that = "above mentioned" was better said as = "entwined".

 

Andy

On 1 Aug 2012, at 14:05, = Andrew Pepperell <apeppere@gmail.com> = wrote:

Hi Roni,

 

While what you say seems to be applicable here to = CLUE, a couple of things spring to mind:

 

- = it's not clear that we'll be declaring SSRC values in SDP as webrtc = dies, so being able to specify imageattr there might not be of = use

 

- = even if we were, there's no obvious defined SSRC <-> media capture = mapping being considered. Specifically, at offer-time the provider = wouldn't know which SSRCs were to be used for which captures and so = wouldn't be able to determine which imageattr values to assign with = which SSRC values.

 

I = can understand how what you describe works fine for webrtc - did you = have a scheme in mind for tackling the above entwined issues (especially = the second one) ?

 

Regards,

 

Andy



On 1 Aug 2012, at 02:25, = "Roni Even" <ron.even.tlv@gmail.com> = wrote:

Andy,

The image attribute provides a better solution  to allow the = consumer to ask for a preferred image size which is not only the aspect = ratio but the resolution and pixel aspect ratio.  It can be = specified per SSRC http://tools.ietf.org/html/draft-lennox-mmusic-sdp-source-selectio= n-03

The consensus in RTCweb was to use this solution  based on http://tools.ietf.org/html/draft-alvestrand-rtcweb-resolution-00 =

 

Roni

 

From:= = Andy Pepperell [mailto:apeppere@gmail.com]
Sent: 01 August, 2012 1:41 AM
To: Allyn Romanow = (allyn)
Cc: Espen Berger (espeberg); Roni Even; = CLUE
Subject: Re: [clue] a few issues on data model = draft

 

>>>Currently = it is not possible to tell whether a remote video source is natively 4:3 = or 16:9, for instance.
>>>If we have this, there might = usefully be a "PREFERRED-ASPECT-RATIO" in the consumer's = stream selection message as part of the  (e.g. in = "<stream-description> / = <encoding>").

>>Roni: RE: No need, first of all = it does not work with switched capture that may have different aspect = ratios. Also this is available in the SDP as well as a way for receiver = to ask for specific ratio using the SDP image attribute.

>AR = =E2=80=93 I=E2=80=99ll let Andy respond to this

Many apologies = for not doing so until now...

Roni, I think you're right in that = at least the native aspect ratio as potentially expressed in a = provider's capture advertisement wouldn't work for the switched capture = case (or at least wouldn't work all the time - for the endpoint case = where the switched capture was a dynamic choice between one of the = "real" cameras' image then it would be possible (and = straightforward) to attach the same native aspect ratio to the switched = capture as was applicable to the non-switched captures). Even if it were = impossible to attach a "native aspect ratio" to the switched = case, to my mind this doesn't necessarily take away from the validity in = this scenario of the consumer supplying a "preferred aspect = ratio" in its stream selection message.

re: use of = "imageattr" in the SDP, it's definitely pertinent here; = potentially this has some issues in relation to CLUE:

- it would = have to be applied on a per m line basis (excluding payload type = differences) rather than per capture - within CLUE there would be a need = (or at least use) of the aspect ratio specification being more = fine-grained and separately specifiable per capture (this may depend in = part on how we eventually choose to manage main vs slides video in terms = of RTP session association though).

- by being in SDP, it's = presumably the case that to correctly signal to the consumer when, say, = a 4:3 presentation source had been connected would require an additional = offer / answer cycle (and similarly if that source were to be = disconnected and a new 16:9 source attached) - this seems slightly less = lightweight than the equivalent operation would be if its scope were = restricted to just the CLUE provider capture advertisement. As a side = point, it also seems more heavyweight than SIP without the use of = imageattr too, where presumably the only impact of connecting such a = presentation source would be a BFCP exchange.

I'm happy to own up = here to not having seen this attribute being present in devices' SDP, so = if any of the above are inaccurate due to my ignorance on this, I = apologise. It would certainly be interesting to get some sort of picture = of the adoption of "imageattr" within the vendor community - I = don't recall seeing this in use, but most of my exposure has been to = systems not necessarily running recent software versions. Obviously if = the already-defined "imageattr" does all we'd like within = CLUE, then we should use this already-defined = scheme.

Regards,

Andy


On Sun, Jul 29, 2012 at 4:58 AM, Allyn Romanow (allyn) = <allyn@cisco.com> = wrote:

Hi Espen,

Thanks for your comments-

Please see below-

Also inline in response to your inline J

 

From:= = Espen Berger (espeberg)
Sent: Monday, July 23, 2012 8:27 = AM
To: Allyn Romanow (allyn); Roni Even; = 'CLUE'


Subject: RE: [clue] a few issues on data = model draft

 <= /o:p>

I have two questions to the data model draft. =

 

The first questions is related to naming differences between the CLUE = framework and the CLUE data model. Some examples of differences. the = framework uses Description and the data model uses capture-scene-text, = the framework uses capture and the data model uses capture-description . = Isn=E2=80=99t it natural that both documents share the same vocabulary? =

 

AR = =E2=80=93 Christian also brought this up.   I believe that the = documents will not have the same vocabulary =E2=80=93 but the concepts = are the same.     The framework was written first = and it=E2=80=99s goal is to describe things as clearly as possible = (we=E2=80=99re not done with that=E2=80=A6). The data model is more = formal and the language there is not casual. It was developed after the = framework, so it sort of distils the ideas in the framework.  =

 

If there = is a discrepancy of meaning, that is an issue and we should definitely = sort it out. But in terms of language, I think it=E2=80=99s fine to = either leave it different or  change the framework at some point to = be more in keeping with the data model.. but I think it=E2=80=99s a good = idea to do that later when the data model is about agreed = upon.           &n= bsp;    

 

I=E2=80=99v= e put this on the list for discussion at the IETF meeting on = Weds.           &n= bsp;           &nb= sp;           &nbs= p;            = ;       =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;    

 

The second questions is related to the concept of doing a data model = as the basis for both advertisement and configuration messages. Playing = around with some XML examples messages it=E2=80=99s not obvious that the = two messages types share a common data model. I do see similarities = between the initial advertisement, the current active configuration and = the advantages of be able to describe the state of a running CLUE = system. Assume this will be sorted out when we look at the details of = how to do configuration in CLUE.  

 

------=_NextPart_000_003C_01CD700D.1D142E40-- From mary.ietf.barnes@gmail.com Wed Aug 1 10:48: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 A4AC811E837F for ; Wed, 1 Aug 2012 10:48:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.702 X-Spam-Level: X-Spam-Status: No, score=-102.702 tagged_above=-999 required=5 tests=[AWL=-0.770, 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 WKmk-Lgj-qww for ; Wed, 1 Aug 2012 10:48:27 -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 21C3D11E8357 for ; Wed, 1 Aug 2012 10:48:25 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so539029lbb.31 for ; Wed, 01 Aug 2012 10:48:25 -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=bHWGcdsK2DjnEJhclwKIZeR2tw7jjoqnOK8+wvGKEZo=; b=gUE76r2t1VzBE25zyYcupCvbxq17qqLdHcTceBH36SEXz5CUDW9RCitaZ0CaKud1wZ Bc3EzEZYUgeNXoUX+okR6GlP+TK3riGc/GLfxPC40Ph/xG2gSuMPx6hiW77YJbk8eiVY TZFUuoBmXYqVpIqgDHflLnCQh2Mvg+Tl55Kg7Hy6wrvlOHPAJpd6p+/sklNw4QHON7ZY qshyfrBqlW59OUHtb8fUd2qwDMvMqpSAApNVVyXvBfhGreOHf8OCrFQ8VabNhpRUaVoq Pp8VxyB80haRXATlttaF8jxS0JIN/Vt0nRjLx47EcOZYa1PQlC2OMxYFRFTtd+qRNveG ls6w== MIME-Version: 1.0 Received: by 10.112.36.42 with SMTP id n10mr8484620lbj.7.1343843304859; Wed, 01 Aug 2012 10:48:24 -0700 (PDT) Received: by 10.112.85.196 with HTTP; Wed, 1 Aug 2012 10:48:24 -0700 (PDT) In-Reply-To: <50174FEE.1080208@nteczone.com> References: <8A527E21B95EF842BC0E952D6E82297747DA1D4A@szxeml527-mbx.china.huawei.com> <8A527E21B95EF842BC0E952D6E82297747DA1F8A@szxeml527-mbx.china.huawei.com> <50114600.3050406@alum.mit.edu> <50121C0B.5080100@nteczone.com> <50174FEE.1080208@nteczone.com> Date: Wed, 1 Aug 2012 12:48:24 -0500 Message-ID: From: Mary Barnes To: Christian Groves Content-Type: multipart/alternative; boundary=e0cb4efe309ed1e70e04c637e61e Cc: "clue@ietf.org" Subject: Re: [clue] FW: New Version Notification for draft-xiao-clue-telemedical-use-case-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: Wed, 01 Aug 2012 17:48:28 -0000 --e0cb4efe309ed1e70e04c637e61e Content-Type: text/plain; charset=ISO-8859-1 (As an individual) Why is it that you think XCON signaling with come after initial CLUE signaling? It is certainly possible to get an XCON notification before doing any CLUE signaling. CLUE will be reusing existing signaling protocols to establish the basic session - that would include using basic SIP conferencing and could include the use of XCON. Mary. On Mon, Jul 30, 2012 at 10:24 PM, Christian Groves < Christian.Groves@nteczone.com> wrote: > Hello Espen, > > The issue that I see is that the conference event package or XCON would > come after the initial CLUE signalling. You may want to chose captures > based on this high level information before XCON etc is established. > However I think the main point is that we need to be a little more detailed > when we describe the use of these fields if people are even now proposing > different uses. > > Regards, Christian > > > On 30/07/2012 11:46 PM, Espen Berger (espeberg) wrote: > >> Hi Christian >> >> If a consumer want to learn about information that's on the level of " >> like "Teleconference Room 2, Beijing" I think its natural to look into >> conference event package or XCON. >> >> In the medical case the description attribute will have values like >> "x-ray" or "CT-scan", "Operation", which is needed since other captures >> attributes will have the same values. >> >> -Espen >> >> >> -----Original Message----- >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of >> Christian Groves >> Sent: 27. juli 2012 06:42 >> To: clue@ietf.org >> Subject: Re: [clue] FW: New Version Notification for >> draft-xiao-clue-telemedical-**use-case-00.txt >> >> Hello Paul, >> >> I think have a enumeration for very specific capabilities woul dbe hard >> but I think there may be some common ones to many conferencing / >> telepresence scenarios. In the discussion of this topic I think that >> perhaps the "description" attribute we have today may be too broad. I was >> thinking it would be used for something like "Teleconference Room 2, >> Beijing" but it seems there's proposals to use this for functional level >> things like "speaker etc". >> >> Regards, Christian >> >> On 26/07/2012 11:28 PM, Paul Kyzivat wrote: >> >>> [as individual] >>> >>> On 7/26/12 2:51 AM, Xiaojing wrote: >>> >>>> Hi Espen, >>>> >>>> Please see my response inline. >>>> >>>> Regards, >>>> Lennard >>>> >>>> -----Original Message----- >>>> From: Espen Berger (espeberg) [mailto:espeberg@cisco.com] >>>> Sent: Wednesday, July 25, 2012 11:19 PM >>>> To: Xiaojing; clue@ietf.org >>>> Subject: RE: [clue] FW: New Version Notification for >>>> draft-xiao-clue-telemedical-**use-case-00.txt >>>> >>>> Thanks for sharing the use case. I had a similar use case in mind, >>>> advanced lecture type calls mainly focusing on P2P with multiple >>>> presentation streams. >>>> >>>> My assumption for an advanced use case like this is each capture has >>>> at least a description field, e.g. 'x-ray' or 'CT-scan', that can be >>>> used by a manual operator to start and stop what to receive. This use >>>> case explains why we need descriptions for both capture-scenes and >>>> captures. >>>> >>>> [Xiao Jing] I share the same thinking on the description field with >>>> you. The different presentations need to be identified from each >>>> other. A straightforward way is to add description tags to them. >>>> >>> I think a textual description is the place to start. >>> It would be hard to start defining a machine-processable enumeration >>> of application-specific categories. >>> >>> We already have the proposal for such a mechanism. >>> This use case simply reinforces the need for that mechanism. >>> >>> Questions >>>> * Do you assume manual or automatic selection of presentation streams? >>>> [Xiao Jing] In my initial thinking, in the use case it is the surgeon >>>> and endpoint users who decide which presentation streams to be sent >>>> and displayed. Thus it is necessary to identify the presentations. >>>> * How do you decide which presentation streams are important? What if >>>> you offer three presentation streams and I can only receive one, how >>>> do I decide which of them to receive? >>>> [Xiao Jing] I assume that the users can differentiate the streams and >>>> then decide which to receive. In this case, if the user knows exactly >>>> what the stream is about, he can decide without additional >>>> information from the provider. But I also think we can introduced >>>> kind of priority concept into it. The "content" attribute could be a >>>> good place to include this idea. In my memory, Christian and Paul are >>>> working on this issue, and I'll try to inform them to take this into >>>> consideration. >>>> * Have you identified additional meta-information to the CLUE >>>> framework needed to describe the information you have in mind writing >>>> up the use case. >>>> [Xiao Jing] In this early stage, I'm just trying to draw concern >>>> about the necessity of having multiple presentation streams. I think >>>> the current framework can cover all the new requirements coming up >>>> with this use case at ease. >>>> >>> I'm not sure whether 'priority' has been brought up on this public >>> list or not. >>> >>> But it is my thought that we need a numeric priority value per >>> capture, that can be used by the recipient when it doesn't have the >>> resources to render even the smallest entry from each scene. *That* >>> would provide a way for the receiving equipment to provide a default >>> rendering. Some endpoints might also provide a gui for the end users >>> to manually configure based on descriptions. >>> >>> The numeric priority could be used to indicate that the presentation >>> is more important than the speaker, or visa versa. And it can be used >>> to indicate a relative priority among presentations. Etc. >>> >>> Thanks, >>> Paul >>> >>> Regards >>>> >>>> -Espen >>>> >>>> >>>> -----Original Message----- >>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf >>>> Of Xiaojing >>>> Sent: 25. juli 2012 04:40 >>>> To: clue@ietf.org >>>> Subject: [clue] FW: New Version Notification for >>>> draft-xiao-clue-telemedical-**use-case-00.txt >>>> >>>> Hi all, >>>> >>>> I've submitted a telemedical use case, which addresses the use of >>>> Telepresence into medical scenarios. >>>> >>>> I think this use case is valid to add another application field where >>>> Telepresence can be used. >>>> So I'd like to suggest adding this use case into the current use case >>>> document. >>>> >>>> Also, along with this use case, some new requirements might come up, >>>> e.g. the requirement to support multiple presentation streams, which >>>> might be considered into the requirement draft. >>>> >>>> Best regards, >>>> Lennard >>>> >>>> -----Original Message----- >>>> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.**org >>>> ] >>>> Sent: Monday, July 09, 2012 11:13 AM >>>> To: Xiaojing >>>> Cc: Roni even >>>> Subject: New Version Notification for >>>> draft-xiao-clue-telemedical-**use-case-00.txt >>>> >>>> >>>> A new version of I-D, draft-xiao-clue-telemedical-**use-case-00.txt >>>> has been successfully submitted by Lennard Xiao and posted to the >>>> IETF repository. >>>> >>>> Filename: draft-xiao-clue-telemedical-**use-case >>>> Revision: 00 >>>> Title: Use Case for Telemedical with Multi-streams >>>> Creation date: 2012-07-06 >>>> WG ID: Individual Submission >>>> Number of pages: 5 >>>> URL: >>>> http://www.ietf.org/internet-**drafts/draft-xiao-clue-** >>>> telemedical-use-c >>>> ase-00.txt >>>> Status: >>>> http://datatracker.ietf.org/**doc/draft-xiao-clue-** >>>> telemedical-use-case >>>> Htmlized: >>>> http://tools.ietf.org/html/**draft-xiao-clue-telemedical-**use-case-00 >>>> >>>> >>>> Abstract: >>>> This memo presenst a telemedicine use case where multiple >>>> presentation streams are used for conveying different information >>>> in >>>> parallel to the main video from the surgery room >>>> >>>> >>>> >>>> >>>> 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 >>> >>> ______________________________**_________________ >> 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 > --e0cb4efe309ed1e70e04c637e61e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable (As an individual)

Why is it that you think XCON signali= ng with come after initial CLUE signaling? =A0It is certainly possible to g= et an XCON notification before doing any CLUE signaling. =A0 CLUE will be r= eusing existing signaling protocols to establish the basic session - that w= ould include using basic SIP conferencing and could include the use of XCON= . =A0 =A0

Mary.=A0

On Mon, Jul = 30, 2012 at 10:24 PM, Christian Groves <Christian.Groves@ntecz= one.com> wrote:
Hello Espen,

The issue that I see is that the conference event package or XCON would com= e after the initial CLUE signalling. You may want to chose captures based o= n this high level information before XCON etc is established. However I thi= nk the main point is that we need to be a little more detailed when we desc= ribe the use of these fields if people are even now proposing different use= s.

Regards, Christian


On 30/07/2012 11:46 PM, Espen Berger (espeberg) wrote:
Hi Christian

If a consumer want to learn about information that's on the level of &q= uot; like "Teleconference Room 2, Beijing" =A0I think its natural= to look into conference event package or XCON.

In the medical case the description attribute will have values like "x= -ray" or "CT-scan", "Operation", which is needed s= ince other captures attributes will have the same values.

-Espen


-----Original Message-----
From: clue-bounc= es@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Christian Groves
Sent: 27. juli 2012 06:42
To: clue@ietf.org Subject: Re: [clue] FW: New Version Notification for draft-xiao-clue-teleme= dical-use-case-00.txt

Hello Paul,

I think have a enumeration for very specific capabilities woul dbe hard but= I think there may be some common ones to many conferencing / telepresence = scenarios. In the discussion of this topic I think that perhaps the "d= escription" attribute we have today may be too broad. I was thinking i= t would be used for something like "Teleconference Room 2, Beijing&quo= t; but it seems there's proposals to use this for functional level thin= gs like "speaker etc".

Regards, Christian

On 26/07/2012 11:28 PM, Paul Kyzivat wrote:
[as individual]

On 7/26/12 2:51 AM, Xiaojing wrote:
Hi Espen,

Please see my response inline.

Regards,
Lennard

-----Original Message-----
From: Espen Berger (espeberg) [mailto:espeberg@cisco.com]
Sent: Wednesday, July 25, 2012 11:19 PM
To: Xiaojing; clue@ietf.= org
Subject: RE: [clue] FW: New Version Notification for
draft-xiao-clue-telemedical-use-case-00.txt

Thanks for sharing the use case. I had a similar use case in mind,
advanced lecture type calls mainly focusing on P2P with multiple
presentation streams.

My assumption for an advanced use case like this is each capture has
at least a description field, e.g. 'x-ray' or =A0'CT-scan',= that can be
used by a manual operator to start and stop what to receive. This use
case explains why we need descriptions for both capture-scenes and
captures.

[Xiao Jing] I share the same thinking on the description field with
you. The different presentations need to be identified from each
other. A straightforward way is to add description tags to them.
I think a textual description is the place to start.
It would be hard to start defining a machine-processable enumeration
of application-specific categories.

We already have the proposal for such a mechanism.
This use case simply reinforces the need for that mechanism.

Questions
* Do you assume manual or automatic selection of presentation streams?
[Xiao Jing] In my initial thinking, in the use case it is the surgeon
and endpoint users who decide which presentation streams to be sent
and displayed. Thus it is necessary to identify the presentations.
* How do you decide which presentation streams are important? What if
you offer three presentation streams and I can only receive one, how
do I decide which of them to receive?
[Xiao Jing] I assume that the users can differentiate the streams and
then decide which to receive. In this case, if the user knows exactly
what the stream is about, he can decide without additional
information from the provider. But I also think we can introduced
kind of priority concept into it. The "content" attribute could b= e a
good place to include this idea. In my memory, Christian and Paul are
working on this issue, and I'll try to inform them to take this into consideration.
* Have you identified additional meta-information to the CLUE
framework needed to describe the information you have in mind writing
up the use case.
[Xiao Jing] In this early stage, I'm just trying to draw concern
about the necessity of having multiple presentation streams. I think
the current framework can cover all the new requirements coming up
with this use case at ease.
I'm not sure whether 'priority' has been brought up on this pub= lic
list or not.

But it is my thought that we need a numeric priority value per
capture, that can be used by the recipient when it doesn't have the
resources to render even the smallest entry from each scene. *That*
would provide a way for the receiving equipment to provide a default
rendering. Some endpoints might also provide a gui for the end users
to manually configure based on descriptions.

The numeric priority could be used to indicate that the presentation
is more important than the speaker, or visa versa. And it can be used
to indicate a relative priority among presentations. Etc.

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

Regards

-Espen


-----Original Message-----
From: clue-bounc= es@ietf.org [mailto:clue-bounces@ietf.org] On Behalf
Of Xiaojing
Sent: 25. juli 2012 04:40
To: clue@ietf.org Subject: [clue] FW: New Version Notification for
draft-xiao-clue-telemedical-use-case-00.txt

Hi all,

I've submitted a telemedical use case, which addresses the use of
Telepresence into medical scenarios.

I think this use case is valid to add another application field where
Telepresence can be used.
So I'd like to suggest adding this use case into the current use case document.

Also, along with this use case, some new requirements might come up,
e.g. the requirement to support multiple presentation streams, which
might be considered into the requirement draft.

Best regards,
Lennard

-----Original Message-----
From: interne= t-drafts@ietf.org [mailto:internet-drafts@ietf.org]
Sent: Monday, July 09, 2012 11:13 AM
To: Xiaojing
Cc: Roni even
Subject: New Version Notification for
draft-xiao-clue-telemedical-use-case-00.txt


A new version of I-D, draft-xiao-clue-telemedical-use-case-00.txt has been successfully submitted by Lennard Xiao and posted to the
IETF repository.

Filename: =A0 =A0 draft-xiao-clue-telemedical-use-case
Revision: =A0 =A0 00
Title: =A0 =A0 =A0 =A0 Use Case for Telemedical with Multi-streams
Creation date: =A0 =A0 2012-07-06
WG ID: =A0 =A0 =A0 =A0 Individual Submission
Number of pages: 5
URL:
http://www.ietf.org/internet-drafts/draft-x= iao-clue-telemedical-use-c
ase-00.txt
Status:
http://datatracker.ietf.org/doc/draft-xiao-c= lue-telemedical-use-case
Htmlized:
http://tools.ietf.org/html/draft-xiao-clue-tel= emedical-use-case-00


Abstract:
=A0 =A0 =A0This memo presenst a telemedicine use case where multiple
=A0 =A0 =A0presentation streams are used for conveying different informatio= n in
=A0 =A0 =A0parallel to the main video from the surgery room




The IETF Secretariat
_______________________________________________
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

_______________________________________________
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


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

--e0cb4efe309ed1e70e04c637e61e-- From ietf@meetecho.com Wed Aug 1 11:29: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 2C4EC11E83D6 for ; Wed, 1 Aug 2012 11:29:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.424 X-Spam-Level: X-Spam-Status: No, score=-0.424 tagged_above=-999 required=5 tests=[AWL=0.295, 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 InaygS8dINPD for ; Wed, 1 Aug 2012 11:29:03 -0700 (PDT) Received: from smtplq03.aruba.it (smtplq-out5.aruba.it [62.149.158.25]) by ietfa.amsl.com (Postfix) with SMTP id C8E6811E810B for ; Wed, 1 Aug 2012 11:29:02 -0700 (PDT) Received: (qmail 9696 invoked by uid 89); 1 Aug 2012 18:29:01 -0000 Received: from unknown (HELO smtp8.aruba.it) (62.149.158.228) by smtplq03.aruba.it with SMTP; 1 Aug 2012 18:29:01 -0000 Received: (qmail 15318 invoked by uid 89); 1 Aug 2012 18:29:01 -0000 Received: from unknown (HELO ?130.129.21.177?) (alex@meetecho.com@130.129.21.177) by smtp8.ad.aruba.it with ESMTPA; 1 Aug 2012 18:29:00 -0000 Message-ID: <50197568.5070204@meetecho.com> Date: Wed, 01 Aug 2012 20:28:56 +0200 From: Meetecho IETF support User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: clue@ietf.org References: <501636C9.5030004@meetecho.com> <5016C519.6060206@meetecho.com> In-Reply-To: <5016C519.6060206@meetecho.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: smtplq03.aruba.it 1.6.2 0/1000/N Subject: Re: [clue] Meetecho support for CLUE 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, 01 Aug 2012 18:29:04 -0000 ...and the same applies for today's second CLUE session. Here is the link: http://www.meetecho.com/ietf84/clue Cheers, the Meetecho team Il 30/07/2012 19:32, Meetecho IETF support ha scritto: > All, > > Meetecho will be available also for today's lunch-time CLUE tutorial. > > Here is the link: > http://www.meetecho.com/ietf84/cluetutorial > > Cheers, > the Meetecho team > > > Il 30/07/2012 09:24, Meetecho IETF support ha scritto: >> Hi all, >> >> a virtual room has been reserved on the Meetecho system for Monday's >> CLUE WG meeting session. >> >> Access to the on-line session (including audio and video streams) will >> be available at: >> http://www.meetecho.com/ietf84/clue >> >> The Meetecho session automatically logs you into the standard IETF >> jabber room. So, from there, you can have an integrated experience >> involving all media and allowing you to interact with the room. >> Remote participants might also send their own voice to the room, if they >> want to, by either calling a landline phone number, or using our >> embedded VoIP applet (in this last case they are *strongly* advised to >> use a headset). >> >> A tutorial of interactivity features of the tool can be found at: >> http://www.meetecho.com/ietf84 >> >> Cheers, >> the Meetecho team >> > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From mary.ietf.barnes@gmail.com Wed Aug 1 14:06: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 57C7511E819B for ; Wed, 1 Aug 2012 14:06:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.527 X-Spam-Level: X-Spam-Status: No, score=-103.527 tagged_above=-999 required=5 tests=[AWL=0.071, 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 wQaKO8aeHXgI for ; Wed, 1 Aug 2012 14:06:35 -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 6783721F86F1 for ; Wed, 1 Aug 2012 14:06:35 -0700 (PDT) Received: by lagv3 with SMTP id v3so5143272lag.31 for ; Wed, 01 Aug 2012 14:06: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=yjGVTf5/7dQGk+5KTlfxnecAsXoqbz27ic1ouekzVkI=; b=dmU/jCsNJ/0Gv/fBqCr3rwQkmVc6dVqfeTGZiiihSaKbk0Gmil0IEogsDxEGchzYfz HPGH6+Q1cC4C+DZ0BWUj08bZF0KyvN2T/4lVL68Tb3wnrS7v+qf3q1Lge9awZILeYC5O b+iaHFdvsZT5d1S8ltkGJ0rNTgNy/1nvaSLAm5arfRMLALoz/Id8m/0gdUbSchyHyhb5 MFL1cFVLLKiuDTxm9VeOHaQJRKi8lAkwE06LFD2dElyvFfRAGD7btvIZ8wMLZnYTrXSi pC8Ky9Z39MEUoHb3ZoTT7F+Y4pLSBCAc8GCuBq1krowzSFXvfHeLtn/mQReXnj5z10Dg nMnw== MIME-Version: 1.0 Received: by 10.112.99.98 with SMTP id ep2mr8935136lbb.45.1343855194273; Wed, 01 Aug 2012 14:06:34 -0700 (PDT) Received: by 10.112.85.196 with HTTP; Wed, 1 Aug 2012 14:06:34 -0700 (PDT) Date: Wed, 1 Aug 2012 16:06:34 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=f46d0401fde17bf9a604c63aab68 Subject: [clue] Note takers for Wed afternoon session 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, 01 Aug 2012 21:06:36 -0000 --f46d0401fde17bf9a604c63aab68 Content-Type: text/plain; charset=ISO-8859-1 It would be helpful if we can get at least two volunteers for taking notes during this afternoon's session ahead of time. If you can hear and can type or write then you are qualified. Also, a jabber scribe would be helpful. Please contact the chairs offlist. Thanks, Mary. --f46d0401fde17bf9a604c63aab68 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable It would be helpful if we can get at least two volunteers for taking notes = during this afternoon's session ahead of time. =A0If you can hear and c= an type or write then you are qualified. =A0 Also, a jabber scribe would be= helpful. =A0

Please contact the chairs offlist.=A0

Thanks,
Mary.=A0
--f46d0401fde17bf9a604c63aab68-- From mary.ietf.barnes@gmail.com Wed Aug 1 18:33: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 88F1811E8165 for ; Wed, 1 Aug 2012 18:33:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.527 X-Spam-Level: X-Spam-Status: No, score=-103.527 tagged_above=-999 required=5 tests=[AWL=0.071, 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 Dnn9si5aSM27 for ; Wed, 1 Aug 2012 18:33:25 -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 3BF9511E8164 for ; Wed, 1 Aug 2012 18:33:25 -0700 (PDT) Received: by lagv3 with SMTP id v3so5237746lag.31 for ; Wed, 01 Aug 2012 18:33: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=u9KZNTgG2TqcfuACD0ATtU8+Lg0DAlgOevlYqMy3RuI=; b=u95eUXmOSRky82FOSPTxGRRQcefCRRA83I6p9aGJx12yzEh6HBcmz8xHU+gz9N81Fw k/pbmquQe8ym6wjIa72KJy+Of2rrgeGbfNKIeelDfzGR6ExLkQRXI+PkpUrx/JXG7naB RK3HM7/9T0QbtGAtd4T5jDWg6YViCGMm8AcW3/DHsubByjjY2PHdTwKLSu9IfuuBwulj 7QY73XUrG/W8amDrmkrOq9GtTmNHzBlGYhBfDOv1OtRFWHhSbSE8oy+oTNnWTPeryWIz ItzFKZWYoOkFuVvImC2Wd2STO7t4IiwmG0ESoGNusU6SO7DfjURXyBJTt+8IF3jOvo0I eTWg== MIME-Version: 1.0 Received: by 10.112.40.33 with SMTP id u1mr8924741lbk.28.1343871204183; Wed, 01 Aug 2012 18:33:24 -0700 (PDT) Received: by 10.112.85.196 with HTTP; Wed, 1 Aug 2012 18:33:24 -0700 (PDT) Date: Wed, 1 Aug 2012 20:33:24 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=e0cb4efe3060bfcf8204c63e65ed Subject: [clue] CLUE WG Interim Meeting (Sept. 2012) Doodle 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, 02 Aug 2012 01:33:26 -0000 --e0cb4efe3060bfcf8204c63e65ed Content-Type: text/plain; charset=ISO-8859-1 Hi all, As noted in the WG session today, we are planning a CLUE WG interim meeting for mid September (week of 17th). Please indicate your availability for Sept. 18-21. We will select two sequential days (i.e., 18-19, 19-20, 20-21) http://www.doodle.com/uzb9nf2h92dqfp5i We have a few people that are looking into the possibility of hosting in San Jose. Note that the focus of this interim is to work out details for the solution. For this meeting to be effective, we need new and updated drafts addressing the problem space categories in the summary slides, which I have uploaded the meeting materials manager: Chairs - agenda & way forward (Wednesday) We will set a draft deadline of one week before the meeting. Regards, Mary. --e0cb4efe3060bfcf8204c63e65ed Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all,

As noted in the WG session today, we are plannin= g a CLUE WG interim meeting for mid September (week of 17th). =A0 Please in= dicate your availability for Sept. 18-21. =A0We will select two sequential = days (i.e., 18-19, 19-20, 20-21)


We have a f= ew people that are looking into the possibility of hosting in San Jose. =A0=

Note that the focus of this interim is to work out deta= ils for the solution. =A0For this meeting to be effective, we need new and = updated drafts addressing the problem space categories in the summary slide= s, which I have uploaded the meeting materials manager:
We will = set a draft deadline of one week before the meeting.=A0

Regards,
Mary.=A0
--e0cb4efe3060bfcf8204c63e65ed-- From ron.even.tlv@gmail.com Thu Aug 2 00:13: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 7A05121F87FF for ; Thu, 2 Aug 2012 00:13:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wfEFIhYuEhWb for ; Thu, 2 Aug 2012 00:13:29 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4EBCD21F87FE for ; Thu, 2 Aug 2012 00:13:26 -0700 (PDT) Received: by ggnc4 with SMTP id c4so8982288ggn.31 for ; Thu, 02 Aug 2012 00:13:25 -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:x-mailer:thread-index:content-language; bh=OKwnuDkJ5eXqvi7BVE5eXNLINsZkUH3fGSIK1rr0GVE=; b=w1RtdhcZdT9eHO5DPv29w6y9yglbV4+3CI/Q1lrXH/j7k/JhsFhsJCXkzX9Oxh4uE3 eqhn30dqYDd5B9RZ5BKXcabHGztbO+PlF0E3Wf4RK1/F4OkwlcYrWzboau/QY8UrkoLY 4JLiVya462AT50gA2sVsve/hE00pn+1f6CbQOenSBceI3qlUhHYaiP1DRA7Tnwvw5uSL Kg+PrM0CIm9NLOJ+TfIBLsPP/WgKrdNJuxHBYgAv6n83cvGJlRQgghZWcRT8G/TTeXtf UW4K9XU+ufJPnU+zffLEf1tZhPfUWDDPM8UfOZ0LDhCUd+790x6U3bHZcZrQzDij8pjI O9ZA== Received: by 10.50.182.232 with SMTP id eh8mr1708172igc.48.1343891605501; Thu, 02 Aug 2012 00:13:25 -0700 (PDT) Received: from RoniE ([2001:df8:0:64:7962:95f2:6735:68f0]) by mx.google.com with ESMTPS id nh1sm15469686igc.11.2012.08.02.00.13.22 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 02 Aug 2012 00:13:24 -0700 (PDT) From: "Roni Even" To: "'Mary Barnes'" , "'CLUE'" References: In-Reply-To: Date: Thu, 2 Aug 2012 10:12:17 +0200 Message-ID: <003b01cd7086$89f29f00$9dd7dd00$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_003C_01CD7097.4D7C3250" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJYPXewWnr+YhqzpjzuaE+crfU2u5YwkPRw Content-Language: en-us Subject: Re: [clue] CLUE WG Interim Meeting (Sept. 2012) Doodle 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, 02 Aug 2012 07:13:30 -0000 This is a multipart message in MIME format. ------=_NextPart_000_003C_01CD7097.4D7C3250 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Mary, The Jewish new year is the 16 and 17 of September. I think that proposing the 18th is not OK. You expect me to accept you not working or travelling on Sunday and still ask me to work on a Friday (my weekend) which I still accept but there is no way I can make it on the 18th to the US without travelling on an important holiday I observe. I ask you to please remove the 18th from the doodle. Thanks Roni From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Mary Barnes Sent: 02 August, 2012 3:33 AM To: CLUE Subject: [clue] CLUE WG Interim Meeting (Sept. 2012) Doodle Hi all, As noted in the WG session today, we are planning a CLUE WG interim meeting for mid September (week of 17th). Please indicate your availability for Sept. 18-21. We will select two sequential days (i.e., 18-19, 19-20, 20-21) http://www.doodle.com/uzb9nf2h92dqfp5i We have a few people that are looking into the possibility of hosting in San Jose. Note that the focus of this interim is to work out details for the solution. For this meeting to be effective, we need new and updated drafts addressing the problem space categories in the summary slides, which I have uploaded the meeting materials manager: Chairs - agenda & way forward (Wednesday) We will set a draft deadline of one week before the meeting. Regards, Mary. ------=_NextPart_000_003C_01CD7097.4D7C3250 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Mary,

The Jewish new year is the 16 and 17 of September. I think that = proposing the 18th is not OK. You expect me to accept you not = working or travelling on Sunday and still ask me to work on a Friday (my = weekend) which I still accept but there is no way I can make it on the = 18th to the US without travelling on an important holiday I = observe.

I ask you to please remove the 18th from the = doodle.

Thanks

Roni

 

From:= = clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of = Mary Barnes
Sent: 02 August, 2012 3:33 AM
To: = CLUE
Subject: [clue] CLUE WG Interim Meeting (Sept. 2012) = Doodle

 

Hi all,

 

As noted in the WG session today, we are planning a = CLUE WG interim meeting for mid September (week of 17th).   Please = indicate your availability for Sept. 18-21.  We will select two = sequential days (i.e., 18-19, 19-20, 20-21)

 

 

We have a few people that are looking into the = possibility of hosting in San Jose.  

 

Note that the focus of this interim is to work out = details for the solution.  For this meeting to be effective, we = need new and updated drafts addressing the problem space categories in = the summary slides, which I have uploaded the meeting materials = manager:

We will = set a draft deadline of one week before the = meeting. 

 

Regards,

Mary. 

------=_NextPart_000_003C_01CD7097.4D7C3250-- From apeppere@gmail.com Thu Aug 2 01:09: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 CBA0E21F8E46 for ; Thu, 2 Aug 2012 01:09:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.303 X-Spam-Level: X-Spam-Status: No, score=-3.303 tagged_above=-999 required=5 tests=[AWL=0.295, 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 55LKHimpnwmc for ; Thu, 2 Aug 2012 01:09:07 -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 E010721F8E3B for ; Thu, 2 Aug 2012 01:09:06 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so8565169vcb.31 for ; Thu, 02 Aug 2012 01:09:06 -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=uU7oxwAC7zNlnY58v8jbSt0DcGuG+J0m9Rme6qv3+Nw=; b=hhetKnHBwJ7h5vclOgIIrNS5L+ghi7d1BHCrZ6hALw3C7mMv+dC4e4SYdBTkp683p/ Jz2sXQ1/akvHITUuBcQUnL9KKmWb04REx6fLxhYnAjlb6A9+EMekx/DVdzJkyQxCjIL/ VKtSooDJBdxqe9E1bbyUD+EB+0iPyhvLrCt+zW82+1n7Uw7wVO8PgY6+KTpg8vl/5HSQ 7Fu0VfLydSda8mcoeusoWAQeY40hvGCNFouvJtMWsGVexgwjTKSlO9QTTy0JpErcDXAR YQnSGlIDtn7sBACAvGs14Z6SORnucm0notBHtdycE+8p+kE6ApbcRQzXh1M+lflkZnpP OSqg== MIME-Version: 1.0 Received: by 10.220.108.15 with SMTP id d15mr19261746vcp.37.1343894946230; Thu, 02 Aug 2012 01:09:06 -0700 (PDT) Received: by 10.220.46.212 with HTTP; Thu, 2 Aug 2012 01:09:05 -0700 (PDT) In-Reply-To: <003b01cd6ffc$59896270$0c9c2750$@gmail.com> References: <003e01cd6f84$86f63120$94e29360$@gmail.com> <36033C16-D22C-4C9C-9B52-EAD2FF9F75AF@gmail.com> <003b01cd6ffc$59896270$0c9c2750$@gmail.com> Date: Thu, 2 Aug 2012 09:09:05 +0100 Message-ID: From: Andy Pepperell To: Roni Even Content-Type: multipart/alternative; boundary=f46d043bdfbee2b21004c643eca6 Cc: CLUE Subject: Re: [clue] a few issues on data model draft 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, 02 Aug 2012 08:09:10 -0000 --f46d043bdfbee2b21004c643eca6 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable >Roni: The SSRC will be known even if not declared in the SDP offer since it will conveyed in any mapping mechanism we are discussing now. (Static in SDP and Dynamic in RTP header extension) The SSRC will certainly be "discovered" in all of these cases, though I'm not sure that equates to "known" for the purposes of this discussion. I'm assuming (please correct me if this isn't true!) that you're talking about "imageattr" being conveyed via offer / answer SDP messages - I do not believe a consumer at least would be able to signal this meaningfully until after it has seen the provider's capture advertisement, which would occur after at least the initial offer / answer (and tt would seem wrong to force a new offer / answer on, say, the basis of a consumer-side layout change). While it would seem feasible to adopt the imageattr syntax within the provider advertisement and consumer choice messages, being forced to supply this information in offer / answer does not (to my mind) seem to work well for CLUE (unlike in webrtc, where it makes perfect sense as webrtc operates within SDP and offer / answer rather than using an additional SCTP-esque messaging channel). >Roni: Note that in any case the consumer cannot ask ahead for a preferred value that will be known by all providers in the MCU case since the media capture is from the MCU and the consumer will need to request it when the switch occurs and he sees a new SSRC. There are scenarios where a consumer *can* usefully ask for a certain aspect ratio from an MCU just fine - I definitely agree that there are cases where it wouldn't be possible (e.g. some switched cases) but I'm not sure that necessarily leads on to your assertion that "the consumer cannot ask ahead for a preferred value [that will be known by all providers] in the MCU case". Regards, Andy On 1 Aug 2012, at 16:42, "Roni Even" wrote: Andy,**** The SSRC will be known even if not declared in the SDP offer since it will conveyed in any mapping mechanism we are discussing now. (Static in SDP and Dynamic in RTP header extension) **** ** ** Note that in any case the consumer cannot ask ahead for a preferred value that will be known by all providers in the MCU case since the media capture is from the MCU and the consumer will need to request it when the switch occurs and he sees a new SSRC.**** ** ** ** ** Roni**** ** ** *From:* Andrew Pepperell [mailto:apeppere@gmail.com] *Sent:* 01 August, 2012 3:53 PM *To:* Andrew Pepperell *Cc:* Roni Even; Allyn Romanow (allyn); Espen Berger (espeberg); CLUE *Subject:* Re: [clue] a few issues on data model draft**** ** ** Thanks to those of you who pointed out my totally non-Freudian slip - "webrtc dies" was meant to be "webrtc does" (!). Maybe I can blame Apple's auto-correct which also decided that "above mentioned" was better said as "entwined".**** ** ** Andy On 1 Aug 2012, at 14:05, Andrew Pepperell wrote:**** Hi Roni,**** ** ** While what you say seems to be applicable here to CLUE, a couple of things spring to mind:**** ** ** - it's not clear that we'll be declaring SSRC values in SDP as webrtc dies, so being able to specify imageattr there might not be of use**** ** ** - even if we were, there's no obvious defined SSRC <-> media capture mapping being considered. Specifically, at offer-time the provider wouldn't know which SSRCs were to be used for which captures and so wouldn't be able to determine which imageattr values to assign with which SSRC values.**** ** ** I can understand how what you describe works fine for webrtc - did you have a scheme in mind for tackling the above entwined issues (especially the second one) ?**** ** ** Regards,**** ** ** Andy**** On 1 Aug 2012, at 02:25, "Roni Even" wrote:**** Andy,**** The image attribute provides a better solution to allow the consumer to ask for a preferred image size which is not only the aspect ratio but the resolution and pixel aspect ratio. It can be specified per SSRC http://tools.ietf.org/html/draft-lennox-mmusic-sdp-source-selection-03 **** The consensus in RTCweb was to use this solution based on http://tools.ietf.org/html/draft-alvestrand-rtcweb-resolution-00 **** **** Roni**** **** *From:* Andy Pepperell [mailto:apeppere@gmail.com] *Sent:* 01 August, 2012 1:41 AM *To:* Allyn Romanow (allyn) *Cc:* Espen Berger (espeberg); Roni Even; CLUE *Subject:* Re: [clue] a few issues on data model draft**** **** >>>Currently it is not possible to tell whether a remote video source is natively 4:3 or 16:9, for instance. >>>If we have this, there might usefully be a "PREFERRED-ASPECT-RATIO" in the consumer's stream selection message as part of the (e.g. in " / "). >>Roni: RE: No need, first of all it does not work with switched capture that may have different aspect ratios. Also this is available in the SDP as well as a way for receiver to ask for specific ratio using the SDP image attribute. >AR =96 I=92ll let Andy respond to this Many apologies for not doing so until now... Roni, I think you're right in that at least the native aspect ratio as potentially expressed in a provider's capture advertisement wouldn't work for the switched capture case (or at least wouldn't work all the time - for the endpoint case where the switched capture was a dynamic choice between one of the "real" cameras' image then it would be possible (and straightforward) to attach the same native aspect ratio to the switched capture as was applicable to the non-switched captures). Even if it were impossible to attach a "native aspect ratio" to the switched case, to my mind this doesn't necessarily take away from the validity in this scenario of the consumer supplying a "preferred aspect ratio" in its stream selection message. re: use of "imageattr" in the SDP, it's definitely pertinent here; potentially this has some issues in relation to CLUE: - it would have to be applied on a per m line basis (excluding payload type differences) rather than per capture - within CLUE there would be a need (or at least use) of the aspect ratio specification being more fine-grained and separately specifiable per capture (this may depend in part on how we eventually choose to manage main vs slides video in terms of RTP session association though). - by being in SDP, it's presumably the case that to correctly signal to the consumer when, say, a 4:3 presentation source had been connected would require an additional offer / answer cycle (and similarly if that source were to be disconnected and a new 16:9 source attached) - this seems slightly less lightweight than the equivalent operation would be if its scope were restricted to just the CLUE provider capture advertisement. As a side point, it also seems more heavyweight than SIP without the use of imageattr too, where presumably the only impact of connecting such a presentation source would be a BFCP exchange. I'm happy to own up here to not having seen this attribute being present in devices' SDP, so if any of the above are inaccurate due to my ignorance on this, I apologise. It would certainly be interesting to get some sort of picture of the adoption of "imageattr" within the vendor community - I don't recall seeing this in use, but most of my exposure has been to systems not necessarily running recent software versions. Obviously if the already-defined "imageattr" does all we'd like within CLUE, then we should use this already-defined scheme. Regards, Andy **** On Sun, Jul 29, 2012 at 4:58 AM, Allyn Romanow (allyn) wrote:**** Hi Espen,**** Thanks for your comments- **** Please see below-**** Also inline in response to your inline J**** **** *From:* Espen Berger (espeberg) *Sent:* Monday, July 23, 2012 8:27 AM *To:* Allyn Romanow (allyn); Roni Even; 'CLUE'**** *Subject:* RE: [clue] a few issues on data model draft**** **** I have two questions to the data model draft. **** **** The first questions is related to naming differences between the CLUE framework and the CLUE data model. Some examples of differences. the framework uses Description and the data model uses capture-scene-text, the framework uses capture and the data model uses capture-description . Isn=92= t it natural that both documents share the same vocabulary? **** **** AR =96 Christian also brought this up. I believe that the documents will not have the same vocabulary =96 but the concepts are the same. The framework was written first and it=92s goal is to describe things as clearl= y as possible (we=92re not done with that=85). The data model is more formal = and the language there is not casual. It was developed after the framework, so it sort of distils the ideas in the framework. **** **** If there is a discrepancy of meaning, that is an issue and we should definitely sort it out. But in terms of language, I think it=92s fine to either leave it different or change the framework at some point to be more in keeping with the data model.. but I think it=92s a good idea to do that later when the data model is about agreed upon. **** **** I=92ve put this on the list for discussion at the IETF meeting on Weds. **** **** The second questions is related to the concept of doing a data model as the basis for both advertisement and configuration messages. Playing around with some XML examples messages it=92s not obvious that the two messages types share a common data model. I do see similarities between the initial advertisement, the current active configuration and the advantages of be able to describe the state of a running CLUE system. Assume this will be sorted out when we look at the details of how to do configuration in CLUE. **** **** --f46d043bdfbee2b21004c643eca6 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
>Roni: The SSRC will be known even if not = declared in the SDP offer since it will conveyed in any mapping mechanism w= e are discussing now. (Static in SDP and Dynamic in RTP header extension)

The SSRC will certainly be "discovered" in al= l of these cases, though I'm not sure that equates to "known"= for the purposes of this discussion.

I'm assu= ming (please correct me if this isn't true!) that you're talking ab= out "imageattr" being conveyed via offer / answer SDP messages - = I do not believe a consumer at least would be able to signal this meaningfu= lly until after it has seen the provider's capture advertisement, which= would occur after at least the initial offer / answer (and tt would seem w= rong to force a new offer / answer on, say, the basis of a consumer-side la= yout change). While it would seem feasible to adopt the imageattr syntax wi= thin the provider advertisement and consumer choice messages, being forced = to supply this information in offer / answer does not (to my mind) seem to = work well for CLUE (unlike in webrtc, where it makes perfect sense as webrt= c operates within SDP and offer / answer rather than using an additional SC= TP-esque messaging channel).

>Roni: Note that in any case the consumer cannot ask= ahead for a preferred value that will be known by all providers in the MCU= case =A0since the media capture is from the MCU and the consumer will need= to request it when the switch occurs and he sees a new SSRC.

There are scenarios where=A0a consumer *can* usefully a= sk for a certain aspect ratio from an MCU just fine - I definitely agree th= at there are cases where it wouldn't be possible (e.g. some switched ca= ses) but I'm not sure that necessarily leads on to your assertion that = "the consumer cannot ask ahead for a preferred value [that will be kno= wn by all providers] in the MCU case".

Regards,

Andy



On 1 Aug 2012, at 16:42, "Roni Even" <ron.even.tlv@gmail.com= > wrote:

Andy,

The SSRC will be known even if not declared in t= he SDP offer since it will conveyed in any mapping mechanism we are discuss= ing now. (Static in SDP and Dynamic in RTP header extension) =

=A0<= /p>

Note that in any case = the consumer cannot ask ahead for a preferred value that will be known by a= ll providers in the MCU case =A0since the media capture is from the MCU and= the consumer will need to request it when the switch occurs and he sees a = new SSRC.

=A0<= /p>

=A0

Roni=

=A0

From: Andrew Pepperell [mailto:apeppere@gmail.com]
Sent: 01 August, 2012 3:53 PM
To: Andrew Pepperell
C= c: Roni Even; Allyn Romanow (allyn); Espen Berger (espeberg); CLUE
<= b>Subject: Re: [clue] a few issues on data model draft

=A0

Thanks to those of you who pointed out my totally non-Freudian sli= p - "webrtc dies" was meant to be "webrtc does" (!). Ma= ybe I can blame Apple's auto-correct which also decided that "abov= e mentioned" was better said as "entwined".

=A0

Andy

On 1 Aug 2012, at= 14:05, Andrew Pepperell <apeppere@gmail.com> wrote:

=

Hi Roni,

=A0

While what y= ou say seems to be applicable here to CLUE, a couple of things spring to mi= nd:

=A0

- it's not clear that we'll be declaring SSRC values= in SDP as webrtc dies, so being able to specify imageattr there might not = be of use

=A0

- even if we were, there's no obvious defined SSRC <-= > media capture mapping being considered. Specifically, at offer-time th= e provider wouldn't know which SSRCs were to be used for which captures= and so wouldn't be able to determine which imageattr values to assign = with which SSRC values.

=A0

I can understand how what you describe works fine for webrtc= - did you have a scheme in mind for tackling the above entwined issues (es= pecially the second one) ?

=A0

Regards,

= =A0

Andy



On 1 Aug 2012= , at 02:25, "Roni Even" <ron.even.tlv@gmail.com> wrote:<= /p>

Andy,

The image attribute provides a better solution= =A0 to allow the consumer to ask for a preferred image size which is not on= ly the aspect ratio but the resolution and pixel aspect ratio. =A0It can be= specified per SSRC http://tools.ietf.org/html/dr= aft-lennox-mmusic-sdp-source-selection-03

The consensus in RTCweb w= as to use this solution =A0based on http://tools.ietf.o= rg/html/draft-alvestrand-rtcweb-resolution-00

=A0<= /p>

Roni<= /u>

=A0<= /p>

From: Andy = Pepperell = [mailto:apeppere@gmail.com]
Sent: 01 August, 2012 1:41 AM
To: Allyn Romanow (allyn)Cc: Espen Berger (espeberg); Roni Even; CLUE
Subject: Re:= [clue] a few issues on data model draft

=A0

= >>>Currently it is not possible to tell whether a remote video sou= rce is natively 4:3 or 16:9, for instance.
>>>If we have this, = there might usefully be a "PREFERRED-ASPECT-RATIO" in the consume= r's stream selection message as part of the=A0 (e.g. in "<strea= m-description> / <encoding>").

>>Roni: RE: No need, first of all it does not work with switched = capture that may have different aspect ratios. Also this is available in th= e SDP as well as a way for receiver to ask for specific ratio using the SDP= image attribute.

>AR =96 I=92ll let Andy respond to this

Many apologies for no= t doing so until now...

Roni, I think you're right in that at le= ast the native aspect ratio as potentially expressed in a provider's ca= pture advertisement wouldn't work for the switched capture case (or at = least wouldn't work all the time - for the endpoint case where the swit= ched capture was a dynamic choice between one of the "real" camer= as' image then it would be possible (and straightforward) to attach the= same native aspect ratio to the switched capture as was applicable to the = non-switched captures). Even if it were impossible to attach a "native= aspect ratio" to the switched case, to my mind this doesn't neces= sarily take away from the validity in this scenario of the consumer supplyi= ng a "preferred aspect ratio" in its stream selection message.
re: use of "imageattr" in the SDP, it's definitely pertin= ent here; potentially this has some issues in relation to CLUE:

- it= would have to be applied on a per m line basis (excluding payload type dif= ferences) rather than per capture - within CLUE there would be a need (or a= t least use) of the aspect ratio specification being more fine-grained and = separately specifiable per capture (this may depend in part on how we event= ually choose to manage main vs slides video in terms of RTP session associa= tion though).

- by being in SDP, it's presumably the case that to correctly signa= l to the consumer when, say, a 4:3 presentation source had been connected w= ould require an additional offer / answer cycle (and similarly if that sour= ce were to be disconnected and a new 16:9 source attached) - this seems sli= ghtly less lightweight than the equivalent operation would be if its scope = were restricted to just the CLUE provider capture advertisement. As a side = point, it also seems more heavyweight than SIP without the use of imageattr= too, where presumably the only impact of connecting such a presentation so= urce would be a BFCP exchange.

I'm happy to own up here to not having seen this attribute being pr= esent in devices' SDP, so if any of the above are inaccurate due to my = ignorance on this, I apologise. It would certainly be interesting to get so= me sort of picture of the adoption of "imageattr" within the vend= or community - I don't recall seeing this in use, but most of my exposu= re has been to systems not necessarily running recent software versions. Ob= viously if the already-defined "imageattr" does all we'd like= within CLUE, then we should use this already-defined scheme.

Regards,

Andy


On Sun, Jul 29, 2012 at 4:58 AM, Allyn Romanow (allyn) <allyn@cisco.com> wrote= :

Hi Espen,

Thanks= for your comments-

Please see below-<= u>

Also inl= ine in response to your inline J

=A0<= /p>

From: Espen Be= rger (espeberg)
Sent: Monday, July 23, 2012 8:27 AM
To: Allyn Romanow (all= yn); Roni Even; 'CLUE'


Subject: RE: [clue] a few issues on data model draft<= /u>

=A0

I have two questions to= the data model draft.

=A0

The first questions is related to naming differences between t= he CLUE framework and the CLUE data model. Some examples of differences. th= e framework uses Description and the data model uses capture-scene-text, th= e framework uses capture and the data model uses capture-description . Isn= =92t it natural that both documents share the same vocabulary?

=A0=

AR =96 Christian also brought this up. =A0=A0I believe that the documents= will not have the same vocabulary =96 but the concepts are the same.=A0=A0= =A0=A0 The framework was written first and it=92s goal is to describe thing= s as clearly as possible (we=92re not done with that=85). The data model is= more formal and the language there is not casual. It was developed after t= he framework, so it sort of distils the ideas in the framework.=A0 <= u>

=A0=

If there is a discre= pancy of meaning, that is an issue and we should definitely sort it out. Bu= t in terms of language, I think it=92s fine to either leave it different or= =A0 change the framework at some point to be more in keeping with the data = model.. but I think it=92s a good idea to do that later when the data model= is about agreed upon.=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0

=A0=

I=92ve put this on t= he list for discussion at the IETF meeting on Weds.=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=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=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

The second questions is related to the concept of doing a data= model as the basis for both advertisement and configuration messages. Play= ing around with some XML examples messages it=92s not obvious that the two = messages types share a common data model. I do see similarities between the= initial advertisement, the current active configuration and the advantages= of be able to describe the state of a running CLUE system. Assume this wil= l be sorted out when we look at the details of how to do configuration in C= LUE. =A0

=A0=

--f46d043bdfbee2b21004c643eca6-- From mary.ietf.barnes@gmail.com Thu Aug 2 06:08: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 623AF21F8569 for ; Thu, 2 Aug 2012 06:08:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.528 X-Spam-Level: X-Spam-Status: No, score=-103.528 tagged_above=-999 required=5 tests=[AWL=0.070, 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 GxtCcAu+hX3O for ; Thu, 2 Aug 2012 06:08:06 -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 EA77421F855E for ; Thu, 2 Aug 2012 06:08:05 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so1036169lbb.31 for ; Thu, 02 Aug 2012 06:08: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=wH1ix9hs9we3PG+s1zX8tZY+SmYy3VJnfl+gQMLkon0=; b=ptHhsa1XyfkBcEwbuMpp5qlx00cGe/3Oas7msh9IdCgyqMkpgjctmS9C3iLFjXw8RZ FLQEk7E7z64xSXlH9Us8kIBHjliyMIh5CEBsUS2bRu3cLjD5ALArBA9gBlxeyfgN+gUT MxcaKgr9tQuLjYp/YcDYfkv8RLOlMaHda1QFzqpa8zYgfdJ9BnsxkOG7E4kHiTvUHxAQ UFqwOm1NCdxvvNT7+QvJY4MuKsG0pzY/+Ipr336vq4hw+F5sAxxv8MR0WzdyftxJET2G ZK0WxzPKE8GV/GZ/Xonc6QySMGGE7T/GWAErfO+4oWI1OPs07KEqBXwpvRQoYs7xyBWF GiBQ== MIME-Version: 1.0 Received: by 10.152.104.44 with SMTP id gb12mr21552122lab.29.1343912884866; Thu, 02 Aug 2012 06:08:04 -0700 (PDT) Received: by 10.112.85.196 with HTTP; Thu, 2 Aug 2012 06:08:04 -0700 (PDT) In-Reply-To: References: Date: Thu, 2 Aug 2012 08:08:04 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=f46d04088ef51c8f5704c6481abe Subject: Re: [clue] CLUE WG Interim Meeting (Sept. 2012) Doodle 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, 02 Aug 2012 13:08:07 -0000 --f46d04088ef51c8f5704c6481abe Content-Type: text/plain; charset=ISO-8859-1 I have modified the doodle and removed the 18th as I have been informed that won't work for some key folks. So, the options now are 19-20, 20-21. Please fill out the doodle by Friday, August 10th, so we can get a host confirmed for the dates. Thanks, Mary. On Wed, Aug 1, 2012 at 8:33 PM, Mary Barnes wrote: > Hi all, > > As noted in the WG session today, we are planning a CLUE WG interim > meeting for mid September (week of 17th). Please indicate your > availability for Sept. 18-21. We will select two sequential days (i.e., > 18-19, 19-20, 20-21) > > http://www.doodle.com/uzb9nf2h92dqfp5i > > We have a few people that are looking into the possibility of hosting in > San Jose. > > Note that the focus of this interim is to work out details for the > solution. For this meeting to be effective, we need new and updated drafts > addressing the problem space categories in the summary slides, which I have > uploaded the meeting materials manager: > Chairs - agenda & way forward (Wednesday) > We will set a draft deadline of one week before the meeting. > > Regards, > Mary. > --f46d04088ef51c8f5704c6481abe Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I have modified the doodle and removed the 18th as I have been informed tha= t won't work for some key folks. So, the options now are 19-20, 20-21.<= div>
Please fill out the doodle by Friday, August 10th, so we= can get a host confirmed for the dates.

Thanks,
Mary.

On Wed, Aug 1, 2012 at 8:33 PM, Mary Barnes <mary.ietf.barnes@= gmail.com> wrote:
Hi all,

As noted in the W= G session today, we are planning a CLUE WG interim meeting for mid Septembe= r (week of 17th). =A0 Please indicate your availability for Sept. 18-21. = =A0We will select two sequential days (i.e., 18-19, 19-20, 20-21)


We have a few people that are looking into the possibility of hostin= g in San Jose. =A0

Note that the focus of this interim is to work out deta= ils for the solution. =A0For this meeting to be effective, we need new and = updated drafts addressing the problem space categories in the summary slide= s, which I have uploaded the meeting materials manager:
Chairs - agenda & way forward (Wednesday)<= /div>
We will set a draft deadline of one week before the meeting.=A0

Regards,
Mary.=A0

--f46d04088ef51c8f5704c6481abe-- From ron.even.tlv@gmail.com Thu Aug 2 07:13:01 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 3B64121F8683 for ; Thu, 2 Aug 2012 07:13:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MUjqoozEXqGR for ; Thu, 2 Aug 2012 07:12:54 -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 9C0C321F8682 for ; Thu, 2 Aug 2012 07:12:54 -0700 (PDT) Received: by yhq56 with SMTP id 56so9462244yhq.31 for ; Thu, 02 Aug 2012 07:12: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:x-mailer:thread-index:content-language; bh=Jsh+22lZhZMVGh8n2f54mxiM3ZdBUSAwP9hDNgiFFwg=; b=g7jcQ4O3qQMdNd7vXAXsUkenkmMYXsJ4ZPVfMHHjuIMN2Lh5IlH5oVcX6ZANDYOYq+ MFfmU3vV31yzsdKpv2tTBqCA6Ba0CXq1AO7HsGKPb4zoJQ1zHStl1NsMr17MFmezjnyI ImEcPCKgzar9tDrEzJEVUh/E4GuPIbQ25JpoVkEX007+7B9nsqdtnpKElz2qUwEwCTjJ XFnbhM1UPgE+/nSBDljpwWzRk7rms15gJn3dfVBZbqEtRUBsYscpm0DHMZmcrM0H2BkZ T95zTMe3bth7sz4qJCgP40ifLnk8qFUc5YKXljOvwNtn28kjYkJVmTNX/ecVEb7Nu5p/ G4zQ== Received: by 10.50.100.129 with SMTP id ey1mr3873447igb.35.1343916773942; Thu, 02 Aug 2012 07:12:53 -0700 (PDT) Received: from RoniE ([2001:df8:0:64:7962:95f2:6735:68f0]) by mx.google.com with ESMTPS id k6sm17147514igz.9.2012.08.02.07.12.50 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 02 Aug 2012 07:12:53 -0700 (PDT) From: "Roni Even" To: "'Andy Pepperell'" References: <003e01cd6f84$86f63120$94e29360$@gmail.com> <36033C16-D22C-4C9C-9B52-EAD2FF9F75AF@gmail.com> <003b01cd6ffc$59896270$0c9c2750$@gmail.com> In-Reply-To: Date: Thu, 2 Aug 2012 17:11:43 +0200 Message-ID: <005901cd70c1$2306f530$6914df90$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_005A_01CD70D1.E692F980" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKWYUEgNa6IsauA+88Ek8WS63kd0gI/9J3nAWavt+kB2Sp3NAHl9sadAXQYdo4CDklJEJVdfgsQ Content-Language: en-us Cc: 'CLUE' Subject: Re: [clue] a few issues on data model draft 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, 02 Aug 2012 14:13:01 -0000 This is a multipart message in MIME format. ------=_NextPart_000_005A_01CD70D1.E692F980 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Andy, I suggest we start from the top by having the use case describing why you suggest adding this parameter since it is not explained in the original email. We can discuss it afterwards since I think we may be looking at different usages. Roni From: Andy Pepperell [mailto:apeppere@gmail.com] Sent: 02 August, 2012 10:09 AM To: Roni Even Cc: Allyn Romanow (allyn); Espen Berger(espeberg); CLUE Subject: Re: [clue] a few issues on data model draft >Roni: The SSRC will be known even if not declared in the SDP offer since it will conveyed in any mapping mechanism we are discussing now. (Static in SDP and Dynamic in RTP header extension) The SSRC will certainly be "discovered" in all of these cases, though I'm not sure that equates to "known" for the purposes of this discussion. I'm assuming (please correct me if this isn't true!) that you're talking about "imageattr" being conveyed via offer / answer SDP messages - I do not believe a consumer at least would be able to signal this meaningfully until after it has seen the provider's capture advertisement, which would occur after at least the initial offer / answer (and tt would seem wrong to force a new offer / answer on, say, the basis of a consumer-side layout change). While it would seem feasible to adopt the imageattr syntax within the provider advertisement and consumer choice messages, being forced to supply this information in offer / answer does not (to my mind) seem to work well for CLUE (unlike in webrtc, where it makes perfect sense as webrtc operates within SDP and offer / answer rather than using an additional SCTP-esque messaging channel). >Roni: Note that in any case the consumer cannot ask ahead for a preferred value that will be known by all providers in the MCU case since the media capture is from the MCU and the consumer will need to request it when the switch occurs and he sees a new SSRC. There are scenarios where a consumer *can* usefully ask for a certain aspect ratio from an MCU just fine - I definitely agree that there are cases where it wouldn't be possible (e.g. some switched cases) but I'm not sure that necessarily leads on to your assertion that "the consumer cannot ask ahead for a preferred value [that will be known by all providers] in the MCU case". Regards, Andy On 1 Aug 2012, at 16:42, "Roni Even" wrote: Andy, The SSRC will be known even if not declared in the SDP offer since it will conveyed in any mapping mechanism we are discussing now. (Static in SDP and Dynamic in RTP header extension) Note that in any case the consumer cannot ask ahead for a preferred value that will be known by all providers in the MCU case since the media capture is from the MCU and the consumer will need to request it when the switch occurs and he sees a new SSRC. Roni From: Andrew Pepperell [mailto:apeppere@gmail.com] Sent: 01 August, 2012 3:53 PM To: Andrew Pepperell Cc: Roni Even; Allyn Romanow (allyn); Espen Berger (espeberg); CLUE Subject: Re: [clue] a few issues on data model draft Thanks to those of you who pointed out my totally non-Freudian slip - "webrtc dies" was meant to be "webrtc does" (!). Maybe I can blame Apple's auto-correct which also decided that "above mentioned" was better said as "entwined". Andy On 1 Aug 2012, at 14:05, Andrew Pepperell wrote: Hi Roni, While what you say seems to be applicable here to CLUE, a couple of things spring to mind: - it's not clear that we'll be declaring SSRC values in SDP as webrtc dies, so being able to specify imageattr there might not be of use - even if we were, there's no obvious defined SSRC <-> media capture mapping being considered. Specifically, at offer-time the provider wouldn't know which SSRCs were to be used for which captures and so wouldn't be able to determine which imageattr values to assign with which SSRC values. I can understand how what you describe works fine for webrtc - did you have a scheme in mind for tackling the above entwined issues (especially the second one) ? Regards, Andy On 1 Aug 2012, at 02:25, "Roni Even" wrote: Andy, The image attribute provides a better solution to allow the consumer to ask for a preferred image size which is not only the aspect ratio but the resolution and pixel aspect ratio. It can be specified per SSRC http://tools.ietf.org/html/draft-lennox-mmusic-sdp-source-selection-03 The consensus in RTCweb was to use this solution based on http://tools.ietf.org/html/draft-alvestrand-rtcweb-resolution-00 Roni From: Andy Pepperell [mailto:apeppere@gmail.com] Sent: 01 August, 2012 1:41 AM To: Allyn Romanow (allyn) Cc: Espen Berger (espeberg); Roni Even; CLUE Subject: Re: [clue] a few issues on data model draft >>>Currently it is not possible to tell whether a remote video source is natively 4:3 or 16:9, for instance. >>>If we have this, there might usefully be a "PREFERRED-ASPECT-RATIO" in the consumer's stream selection message as part of the (e.g. in " / "). >>Roni: RE: No need, first of all it does not work with switched capture that may have different aspect ratios. Also this is available in the SDP as well as a way for receiver to ask for specific ratio using the SDP image attribute. >AR - I'll let Andy respond to this Many apologies for not doing so until now... Roni, I think you're right in that at least the native aspect ratio as potentially expressed in a provider's capture advertisement wouldn't work for the switched capture case (or at least wouldn't work all the time - for the endpoint case where the switched capture was a dynamic choice between one of the "real" cameras' image then it would be possible (and straightforward) to attach the same native aspect ratio to the switched capture as was applicable to the non-switched captures). Even if it were impossible to attach a "native aspect ratio" to the switched case, to my mind this doesn't necessarily take away from the validity in this scenario of the consumer supplying a "preferred aspect ratio" in its stream selection message. re: use of "imageattr" in the SDP, it's definitely pertinent here; potentially this has some issues in relation to CLUE: - it would have to be applied on a per m line basis (excluding payload type differences) rather than per capture - within CLUE there would be a need (or at least use) of the aspect ratio specification being more fine-grained and separately specifiable per capture (this may depend in part on how we eventually choose to manage main vs slides video in terms of RTP session association though). - by being in SDP, it's presumably the case that to correctly signal to the consumer when, say, a 4:3 presentation source had been connected would require an additional offer / answer cycle (and similarly if that source were to be disconnected and a new 16:9 source attached) - this seems slightly less lightweight than the equivalent operation would be if its scope were restricted to just the CLUE provider capture advertisement. As a side point, it also seems more heavyweight than SIP without the use of imageattr too, where presumably the only impact of connecting such a presentation source would be a BFCP exchange. I'm happy to own up here to not having seen this attribute being present in devices' SDP, so if any of the above are inaccurate due to my ignorance on this, I apologise. It would certainly be interesting to get some sort of picture of the adoption of "imageattr" within the vendor community - I don't recall seeing this in use, but most of my exposure has been to systems not necessarily running recent software versions. Obviously if the already-defined "imageattr" does all we'd like within CLUE, then we should use this already-defined scheme. Regards, Andy On Sun, Jul 29, 2012 at 4:58 AM, Allyn Romanow (allyn) wrote: Hi Espen, Thanks for your comments- Please see below- Also inline in response to your inline J From: Espen Berger (espeberg) Sent: Monday, July 23, 2012 8:27 AM To: Allyn Romanow (allyn); Roni Even; 'CLUE' Subject: RE: [clue] a few issues on data model draft I have two questions to the data model draft. The first questions is related to naming differences between the CLUE framework and the CLUE data model. Some examples of differences. the framework uses Description and the data model uses capture-scene-text, the framework uses capture and the data model uses capture-description . Isn't it natural that both documents share the same vocabulary? AR - Christian also brought this up. I believe that the documents will not have the same vocabulary - but the concepts are the same. The framework was written first and it's goal is to describe things as clearly as possible (we're not done with that.). The data model is more formal and the language there is not casual. It was developed after the framework, so it sort of distils the ideas in the framework. If there is a discrepancy of meaning, that is an issue and we should definitely sort it out. But in terms of language, I think it's fine to either leave it different or change the framework at some point to be more in keeping with the data model.. but I think it's a good idea to do that later when the data model is about agreed upon. I've put this on the list for discussion at the IETF meeting on Weds. The second questions is related to the concept of doing a data model as the basis for both advertisement and configuration messages. Playing around with some XML examples messages it's not obvious that the two messages types share a common data model. I do see similarities between the initial advertisement, the current active configuration and the advantages of be able to describe the state of a running CLUE system. Assume this will be sorted out when we look at the details of how to do configuration in CLUE. ------=_NextPart_000_005A_01CD70D1.E692F980 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Andy,

I suggest we start from the top by having the use case describing why = you suggest adding this parameter since it is not explained in the = original email. We can discuss it afterwards since I think we may be = looking at different usages.

Roni

 

From:= = Andy Pepperell [mailto:apeppere@gmail.com]
Sent: 02 August, = 2012 10:09 AM
To: Roni Even
Cc: Allyn Romanow = (allyn); Espen Berger(espeberg); CLUE
Subject: Re: [clue] a = few issues on data model draft

 

>Roni: The SSRC will be known even if not declared = in the SDP offer since it will conveyed in any mapping mechanism we are = discussing now. (Static in SDP and Dynamic in RTP header = extension)

 

The SSRC will certainly be "discovered" in = all of these cases, though I'm not sure that equates to = "known" for the purposes of this = discussion.

 

I'm assuming (please correct me if this isn't true!) = that you're talking about "imageattr" being conveyed via offer = / answer SDP messages - I do not believe a consumer at least would be = able to signal this meaningfully until after it has seen the provider's = capture advertisement, which would occur after at least the initial = offer / answer (and tt would seem wrong to force a new offer / answer = on, say, the basis of a consumer-side layout change). While it would = seem feasible to adopt the imageattr syntax within the provider = advertisement and consumer choice messages, being forced to supply this = information in offer / answer does not (to my mind) seem to work well = for CLUE (unlike in webrtc, where it makes perfect sense as webrtc = operates within SDP and offer / answer rather than using an additional = SCTP-esque messaging channel).

 

>Roni: Note that in any case the consumer cannot = ask ahead for a preferred value that will be known by all providers in = the MCU case  since the media capture is from the MCU and the = consumer will need to request it when the switch occurs and he sees a = new SSRC.

 

There are scenarios where a consumer *can* = usefully ask for a certain aspect ratio from an MCU just fine - I = definitely agree that there are cases where it wouldn't be possible = (e.g. some switched cases) but I'm not sure that necessarily leads on to = your assertion that "the consumer cannot ask ahead for a preferred = value [that will be known by all providers] in the MCU = case".

 

Regards,

 

Andy

 



On 1 Aug 2012, at 16:42, = "Roni Even" <ron.even.tlv@gmail.com> = wrote:

Andy,

The SSRC will be known even if not declared in the SDP offer since it = will conveyed in any mapping mechanism we are discussing now. (Static in = SDP and Dynamic in RTP header extension)

 

Note that in any case the consumer cannot ask ahead for a preferred = value that will be known by all providers in the MCU case  since = the media capture is from the MCU and the consumer will need to request = it when the switch occurs and he sees a new = SSRC.

 

 

Roni

 

From:= = Andrew Pepperell [mailto:apeppere@gmail.com]
Sent: 01 August, = 2012 3:53 PM
To: Andrew Pepperell
Cc: Roni Even; = Allyn Romanow (allyn); Espen Berger (espeberg); CLUE
Subject: = Re: [clue] a few issues on data model = draft

 <= /o:p>

Thanks to = those of you who pointed out my totally non-Freudian slip - "webrtc = dies" was meant to be "webrtc does" (!). Maybe I can = blame Apple's auto-correct which also decided that "above = mentioned" was better said as = "entwined".

 <= /o:p>

Andy

On 1 = Aug 2012, at 14:05, Andrew Pepperell <apeppere@gmail.com> = wrote:

Hi = Roni,

 <= /o:p>

While what = you say seems to be applicable here to CLUE, a couple of things spring = to mind:

 <= /o:p>

- it's not = clear that we'll be declaring SSRC values in SDP as webrtc dies, so = being able to specify imageattr there might not be of = use

 <= /o:p>

- even if = we were, there's no obvious defined SSRC <-> media capture mapping = being considered. Specifically, at offer-time the provider wouldn't know = which SSRCs were to be used for which captures and so wouldn't be able = to determine which imageattr values to assign with which SSRC = values.

 <= /o:p>

I can = understand how what you describe works fine for webrtc - did you have a = scheme in mind for tackling the above entwined issues (especially the = second one) ?

 <= /o:p>

Regards,

 <= /o:p>

Andy



On 1 Aug = 2012, at 02:25, "Roni Even" <ron.even.tlv@gmail.com> = wrote:

Andy,

The image attribute provides a better solution  to allow the = consumer to ask for a preferred image size which is not only the aspect = ratio but the resolution and pixel aspect ratio.  It can be = specified per SSRC http://tools.ietf.org/html/draft-lennox-mmusic-sdp-sour= ce-selection-03

The consensus in RTCweb was to use this solution  based on http://tools.ietf.org/html/draft-alvestrand-rtcweb-reso= lution-00

 

Roni

 

From:= = Andy Pepperell [mailto:apeppere@gmail.com]
Sent: 01 = August, 2012 1:41 AM
To: Allyn Romanow (allyn)
Cc: = Espen Berger (espeberg); Roni Even; CLUE
Subject: Re: [clue] a = few issues on data model draft

 <= /o:p>

>>>Curren= tly it is not possible to tell whether a remote video source is natively = 4:3 or 16:9, for instance.
>>>If we have this, there might = usefully be a "PREFERRED-ASPECT-RATIO" in the consumer's = stream selection message as part of the  (e.g. in = "<stream-description> / = <encoding>").

>>Roni: RE: No need, first of all = it does not work with switched capture that may have different aspect = ratios. Also this is available in the SDP as well as a way for receiver = to ask for specific ratio using the SDP image attribute.

>AR = – I’ll let Andy respond to this

Many apologies for = not doing so until now...

Roni, I think you're right in that at = least the native aspect ratio as potentially expressed in a provider's = capture advertisement wouldn't work for the switched capture case (or at = least wouldn't work all the time - for the endpoint case where the = switched capture was a dynamic choice between one of the = "real" cameras' image then it would be possible (and = straightforward) to attach the same native aspect ratio to the switched = capture as was applicable to the non-switched captures). Even if it were = impossible to attach a "native aspect ratio" to the switched = case, to my mind this doesn't necessarily take away from the validity in = this scenario of the consumer supplying a "preferred aspect = ratio" in its stream selection message.

re: use of = "imageattr" in the SDP, it's definitely pertinent here; = potentially this has some issues in relation to CLUE:

- it would = have to be applied on a per m line basis (excluding payload type = differences) rather than per capture - within CLUE there would be a need = (or at least use) of the aspect ratio specification being more = fine-grained and separately specifiable per capture (this may depend in = part on how we eventually choose to manage main vs slides video in terms = of RTP session association though).

- by being in SDP, it's = presumably the case that to correctly signal to the consumer when, say, = a 4:3 presentation source had been connected would require an additional = offer / answer cycle (and similarly if that source were to be = disconnected and a new 16:9 source attached) - this seems slightly less = lightweight than the equivalent operation would be if its scope were = restricted to just the CLUE provider capture advertisement. As a side = point, it also seems more heavyweight than SIP without the use of = imageattr too, where presumably the only impact of connecting such a = presentation source would be a BFCP exchange.

I'm happy to own up = here to not having seen this attribute being present in devices' SDP, so = if any of the above are inaccurate due to my ignorance on this, I = apologise. It would certainly be interesting to get some sort of picture = of the adoption of "imageattr" within the vendor community - I = don't recall seeing this in use, but most of my exposure has been to = systems not necessarily running recent software versions. Obviously if = the already-defined "imageattr" does all we'd like within = CLUE, then we should use this already-defined = scheme.

Regards,

Andy

On Sun, Jul = 29, 2012 at 4:58 AM, Allyn Romanow (allyn) <allyn@cisco.com> = wrote:

Hi Espen,

Thanks for your comments-

Please see below-

Also inline in response to your inline J

 

From:= = Espen Berger (espeberg)
Sent: Monday, July 23, 2012 8:27 = AM
To: Allyn Romanow (allyn); Roni Even; = 'CLUE'


Subje= ct: RE: [clue] a few issues on data model = draft

 <= /o:p>

I have two questions to the data model draft. =

 

The first questions is related to naming differences between the CLUE = framework and the CLUE data model. Some examples of differences. the = framework uses Description and the data model uses capture-scene-text, = the framework uses capture and the data model uses capture-description . = Isn’t it natural that both documents share the same vocabulary? =

 

AR – = Christian also brought this up.   I believe that the documents = will not have the same vocabulary – but the concepts are the = same.     The framework was written first and = it’s goal is to describe things as clearly as possible = (we’re not done with that…). The data model is more formal = and the language there is not casual. It was developed after the = framework, so it sort of distils the ideas in the framework.  =

 

If there = is a discrepancy of meaning, that is an issue and we should definitely = sort it out. But in terms of language, I think it’s fine to either = leave it different or  change the framework at some point to be = more in keeping with the data model.. but I think it’s a good idea = to do that later when the data model is about agreed = upon.           &n= bsp;    

 

I’ve = put this on the list for discussion at the IETF meeting on = Weds.           &n= bsp;           &nb= sp;           &nbs= p;            = ;       =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;    

 

The second questions is related to the concept of doing a data model = as the basis for both advertisement and configuration messages. Playing = around with some XML examples messages it’s not obvious that the = two messages types share a common data model. I do see similarities = between the initial advertisement, the current active configuration and = the advantages of be able to describe the state of a running CLUE = system. Assume this will be sorted out when we look at the details of = how to do configuration in CLUE.  

 

------=_NextPart_000_005A_01CD70D1.E692F980-- From ietf@meetecho.com Thu Aug 2 14:50: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 D88BF11E8147 for ; Thu, 2 Aug 2012 14:50:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.555 X-Spam-Level: X-Spam-Status: No, score=-0.555 tagged_above=-999 required=5 tests=[AWL=0.164, 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 ZdXfI7gBjDNT for ; Thu, 2 Aug 2012 14:50:27 -0700 (PDT) Received: from smtplq02.aruba.it (smtplqs-out17.aruba.it [62.149.158.57]) by ietfa.amsl.com (Postfix) with SMTP id 2FCA211E8127 for ; Thu, 2 Aug 2012 14:50:25 -0700 (PDT) Received: (qmail 4631 invoked by uid 89); 2 Aug 2012 21:50:23 -0000 Received: from unknown (HELO smtp4.aruba.it) (62.149.158.224) by smtplq02.aruba.it with SMTP; 2 Aug 2012 21:50:23 -0000 Received: (qmail 23298 invoked by uid 89); 2 Aug 2012 21:50:23 -0000 Received: from unknown (HELO ?130.129.21.177?) (alex@meetecho.com@130.129.21.177) by smtp4.ad.aruba.it with ESMTPA; 2 Aug 2012 21:50:22 -0000 Message-ID: <501AF617.6030109@meetecho.com> Date: Thu, 02 Aug 2012 23:50:15 +0200 From: Meetecho IETF support User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: clue@ietf.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: smtplq02.aruba.it 1.6.2 0/1000/N Subject: [clue] Meetecho session recordings available 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, 02 Aug 2012 21:50:29 -0000 Dear all, the full recording (synchronized video, audio, slides and jabber room) of the three CLUE sessions at IETF-84 are available. You can watch them by accessing the following URLs: CLUE I: http://ietf84.conf.meetecho.com/index.php/Recorded_Sessions#IETF84_CLUE CLUE II: http://ietf84.conf.meetecho.com/index.php/Recorded_Sessions#IETF84_CLUE_II CLUE Tutorial: http://ietf84.conf.meetecho.com/index.php/Recorded_Sessions#IETF84_CLUE_TUTORIAL For the chair(s): please feel free to put the link to the recording in the minutes, if you think this might be useful. In case of problems with the playout, just drop an e-mail to team@meetecho.com. Cheers, the Meetecho team -- Meetecho s.r.l. Web Conferencing and Collaboration Tools www.meetecho.com From mary.ietf.barnes@gmail.com Thu Aug 2 17:47: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 AAA8C21F84FC for ; Thu, 2 Aug 2012 17:47:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.697 X-Spam-Level: X-Spam-Status: No, score=-102.697 tagged_above=-999 required=5 tests=[AWL=-0.765, 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 2HjqIvnVajgj for ; Thu, 2 Aug 2012 17:47:24 -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 6106621F8516 for ; Thu, 2 Aug 2012 17:47:24 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so1391537lbb.31 for ; Thu, 02 Aug 2012 17:47:23 -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=TS72+UN7lP7QVVqK5eNpWBdNEXYx+Q+SmA8KuUEEAE0=; b=rFzpa5jCkG5E+oqx2TWdQEZ5QnHlTJFOgMA/tcS2+m9OYh1w2TSA7zsiUFQIGY6tsQ DlnD+k1HMt6kBv/JQeBYL6wWP6awvhq+jCdjVbuiIV+AvxlTrDYy5G83GPbhnR8jns6g mDKGMtb14p4MRCx4nICtGpoJE9M+VFlpSKJgJVXf8GM1zeGbnYr57eMIQ0NxgMqYeHxW lfB6e8rDlPtosurrV6hWwV/EW41IsdIv0vwxQe6Lh0MZj//m9KCxIVcMNJfWAkhgxICZ oVfotY6mIhc6j0ata5Q95TorW0RfScBflz480YibAnPkhlxC3+JtmTDlbs3hG5A+scO8 k0qA== MIME-Version: 1.0 Received: by 10.152.135.200 with SMTP id pu8mr23088170lab.8.1343954843359; Thu, 02 Aug 2012 17:47:23 -0700 (PDT) Received: by 10.112.85.196 with HTTP; Thu, 2 Aug 2012 17:47:23 -0700 (PDT) In-Reply-To: <501AF617.6030109@meetecho.com> References: <501AF617.6030109@meetecho.com> Date: Thu, 2 Aug 2012 19:47:23 -0500 Message-ID: From: Mary Barnes To: Meetecho IETF support Content-Type: multipart/alternative; boundary=f46d04374547085add04c651dfa4 Cc: clue@ietf.org Subject: Re: [clue] Meetecho session recordings available 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, 03 Aug 2012 00:47:25 -0000 --f46d04374547085add04c651dfa4 Content-Type: text/plain; charset=ISO-8859-1 Thanks! We really appreciate the time and effort you all put into this. Mary. On Thu, Aug 2, 2012 at 4:50 PM, Meetecho IETF support wrote: > Dear all, > > the full recording (synchronized video, audio, slides and jabber room) > of the three CLUE sessions at IETF-84 are available. > > You can watch them by accessing the following URLs: > > CLUE I: > http://ietf84.conf.meetecho.**com/index.php/Recorded_** > Sessions#IETF84_CLUE > > CLUE II: > http://ietf84.conf.meetecho.**com/index.php/Recorded_** > Sessions#IETF84_CLUE_II > > CLUE Tutorial: > http://ietf84.conf.meetecho.**com/index.php/Recorded_** > Sessions#IETF84_CLUE_TUTORIAL > > For the chair(s): please feel free to put the link to the recording in the > minutes, if you think this might be useful. > > In case of problems with the playout, just drop an e-mail to > team@meetecho.com. > > Cheers, > the Meetecho team > > -- > Meetecho s.r.l. > Web Conferencing and Collaboration Tools > www.meetecho.com > > ______________________________**_________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/**listinfo/clue > --f46d04374547085add04c651dfa4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thanks! =A0We really appreciate the time and effort you all put into this.= =A0

Mary.

On Thu, Aug = 2, 2012 at 4:50 PM, Meetecho IETF support <ietf@meetecho.com> wrote:
Dear all,

the full recording (synchronized video, audio, slides and jabber room)
of the three CLUE sessions at IETF-84 are available.

You can watch them by accessing the following URLs:

CLUE I:
http://ietf84.conf.meetecho.com/index.php= /Recorded_Sessions#IETF84_CLUE

CLUE II:
http://ietf84.conf.meetecho.com/index.= php/Recorded_Sessions#IETF84_CLUE_II

CLUE Tutorial:
http://ietf84.conf.meetecho.com/= index.php/Recorded_Sessions#IETF84_CLUE_TUTORIAL

For the chair(s): please feel free to put the link to the recording in the = minutes, if you think this might be useful.

In case of problems with the playout, just drop an e-mail to team@meetecho.com.

Cheers,
the Meetecho team

--
Meetecho s.r.l.
Web Conferencing and Collaboration Tools
www.meetecho.com<= br>
_______________________________________________
clue mailing list
clue@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/clue

--f46d04374547085add04c651dfa4-- From pkyzivat@alum.mit.edu Mon Aug 6 14:01: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 7BE2411E80A5 for ; Mon, 6 Aug 2012 14:01:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.296 X-Spam-Level: X-Spam-Status: No, score=-2.296 tagged_above=-999 required=5 tests=[AWL=0.303, 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 c6SilwU5gskf for ; Mon, 6 Aug 2012 14:01:37 -0700 (PDT) Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [76.96.59.227]) by ietfa.amsl.com (Postfix) with ESMTP id 5813911E80A4 for ; Mon, 6 Aug 2012 14:01:37 -0700 (PDT) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta12.westchester.pa.mail.comcast.net with comcast id jX5B1j0051c6gX85CZ1fGs; Mon, 06 Aug 2012 21:01:39 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta23.westchester.pa.mail.comcast.net with comcast id jZ1N1j00B3ZTu2S3jZ1NXN; Mon, 06 Aug 2012 21:01:22 +0000 Message-ID: <502030B7.1090704@alum.mit.edu> Date: Mon, 06 Aug 2012 14:01:43 -0700 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: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] CLUE WG Interim Meeting (Sept. 2012) Doodle 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, 06 Aug 2012 21:01:38 -0000 People - *please* express your preference in this doodle poll ASAP, so we can nail down a venue! The possible dates are quite constrained due to a variety of issues, but we still need you to vote so we can decide if there is a quorum for having the meeting. Thanks, Paul On 8/1/12 6:33 PM, Mary Barnes wrote: > Hi all, > > As noted in the WG session today, we are planning a CLUE WG interim > meeting for mid September (week of 17th). Please indicate your > availability for Sept. 18-21. We will select two sequential days (i.e., > 18-19, 19-20, 20-21) > > http://www.doodle.com/uzb9nf2h92dqfp5i > > We have a few people that are looking into the possibility of hosting in > San Jose. > > Note that the focus of this interim is to work out details for the > solution. For this meeting to be effective, we need new and updated > drafts addressing the problem space categories in the summary slides, > which I have uploaded the meeting materials manager: > Chairs - agenda & way forward (Wednesday) > > We will set a draft deadline of one week before the meeting. > > Regards, > Mary. From pkyzivat@alum.mit.edu Mon Aug 6 15:19: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 E5C4A21F8508 for ; Mon, 6 Aug 2012 15:19:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.219 X-Spam-Level: X-Spam-Status: No, score=-1.219 tagged_above=-999 required=5 tests=[AWL=-0.782, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.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 Oj1pywCqeyyp for ; Mon, 6 Aug 2012 15:19:54 -0700 (PDT) Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:24]) by ietfa.amsl.com (Postfix) with ESMTP id 6946821F8503 for ; Mon, 6 Aug 2012 15:19:54 -0700 (PDT) Received: from omta16.westchester.pa.mail.comcast.net ([76.96.62.88]) by qmta02.westchester.pa.mail.comcast.net with comcast id jPTY1j0051uE5Es51aKxuy; Mon, 06 Aug 2012 22:19:57 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta16.westchester.pa.mail.comcast.net with comcast id jaL41j0013ZTu2S3caL42d; Mon, 06 Aug 2012 22:20:04 +0000 Message-ID: <50204308.7040900@alum.mit.edu> Date: Mon, 06 Aug 2012 15:19:52 -0700 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: In-Reply-To: X-Forwarded-Message-Id: Content-Type: multipart/mixed; boundary="------------010809070403060701040902" Subject: [clue] Fwd: [MMUSIC] Channel descriptions 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, 06 Aug 2012 22:19:56 -0000 This is a multi-part message in MIME format. --------------010809070403060701040902 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit As described below, ISTM what is being described below could be similar to a clue audio capture. But the context in which this is being discussed is not clue. I think we need to pay attention to whether this can lead to an independent definition of essentially the same thing. Thanks, Paul -------- Original Message -------- Subject: Re: [MMUSIC] Channel descriptions Date: Fri, 20 Jul 2012 08:44:05 -0600 From: Kevin Gross To: Harald Alvestrand CC: mmusic@ietf.org I'm talking about a single audio signals. It a surround stream, a single signal would be, for instance, the left front. Track is also a reasonable description but people tend to associate that term with recording and reproduction. The ability to label individual channels in surround formats is important to distinguish the many formats and conventions in use. See http://tech.ebu.ch/docs/r/r123.pdf. In commercial applications, it is common, for efficiency, for multiple loosely related channels to be carried in the same stream, e.g. different background music source, paging signals for different zones. Active audio crossover networks (http://en.wikipedia.org/wiki/Audio_crossover#Active) are often used in large sound reinforcement systems and different frequency components are carried to the speakers as separate channels in the same stream. In all cases it is important to correctly connect the channels to their intended destinations. There are too many possibilities in most of these use cases for the i= description to resolve the potential ambiguity. Kevin Gross On Fri, Jul 20, 2012 at 6:13 AM, Harald Alvestrand > wrote: Kevin, can you clarify what you mean by "channel" here? The term is used most often for components of a multisource audio signal, such as stereo, 5+1 or 22+2 - in most cases, those will be carried in a single SSRC, using an encoding that implicitly defines which channels go where. In WebRTC, we've converged on the word "track" for a single media flow such as one audio signal (mostly) carried in a single SSRC, and the word "stream" for multiple media flows (such as audio and video) that are related to each other in some fashion. If you have a definition you would like to use, please point to it - the discussion can get to be almighty confusing if we're not talking about the same thing! On 07/18/2012 01:57 AM, Kevin Gross wrote: > The i= attribute provides a means to describe a session. Sessions > often have multiple media streams or channels. Although RFC 3551 > (page 8) suggests a convention for ordering of channels for > surround sound applications, other applications use multiple > channels in different ways. It would be useful if there were a > mechanism analogous to i= for describing individual channels in a > session. Does such a thing exist anywhere? I've searched the > archives here and didn't find anything. > > Kevin Gross > +1-303-447-0517 > Media Network Consultant > AVA Networks - www.AVAnw.com , www.X192.org > > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic --------------010809070403060701040902 Content-Type: text/plain; charset=UTF-8; name="Attached Message Part" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Attached Message Part" _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic --------------010809070403060701040902-- From Christian.Groves@nteczone.com Tue Aug 7 22:44: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 7695721F8549 for ; Tue, 7 Aug 2012 22:44:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.489 X-Spam-Level: X-Spam-Status: No, score=-2.489 tagged_above=-999 required=5 tests=[AWL=0.110, 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 IXTp0gZV2FeZ for ; Tue, 7 Aug 2012 22:44:51 -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 7C0D321F854A for ; Tue, 7 Aug 2012 22:44:49 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBAFP8IVB20Y33/2dsb2JhbAANLgq9EwEBAQQBAQE1GxUGBgECAQEMBAsRBAEBAQkWCAcJAwIBAgEVHwgBCAYNAQUCAQEFiA+mfZQdiw8KBoZQA5ZckWk Received: from ppp118-209-141-247.lns20.mel6.internode.on.net (HELO [127.0.0.1]) ([118.209.141.247]) by ipmail06.adl6.internode.on.net with ESMTP; 08 Aug 2012 15:14:46 +0930 Message-ID: <5021FCC7.6070304@nteczone.com> Date: Wed, 08 Aug 2012 15:44:39 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Mary Barnes References: <8A527E21B95EF842BC0E952D6E82297747DA1D4A@szxeml527-mbx.china.huawei.com> <8A527E21B95EF842BC0E952D6E82297747DA1F8A@szxeml527-mbx.china.huawei.com> <50114600.3050406@alum.mit.edu> <50121C0B.5080100@nteczone.com> <50174FEE.1080208@nteczone.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "clue@ietf.org" Subject: Re: [clue] FW: New Version Notification for draft-xiao-clue-telemedical-use-case-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: Wed, 08 Aug 2012 05:44:52 -0000 Hello Mary, I guess the reason why is the same reason why the media streams will likely be set up after CLUE. There could be potentially a large possible set of captures/configurations that you want to narrow down before you start assigning resources to them. You want to have enough information associated with the captures so that an educated decision can be made about whether to accept/use one. I don't think its enough just to assume that XCON will handle these things. Regards, Christian On 2/08/2012 3:48 AM, Mary Barnes wrote: > (As an individual) > > Why is it that you think XCON signaling with come after initial CLUE > signaling? It is certainly possible to get an XCON notification > before doing any CLUE signaling. CLUE will be reusing existing > signaling protocols to establish the basic session - that would > include using basic SIP conferencing and could include the use of XCON. > > Mary. > > On Mon, Jul 30, 2012 at 10:24 PM, Christian Groves > > > wrote: > > Hello Espen, > > The issue that I see is that the conference event package or XCON > would come after the initial CLUE signalling. You may want to > chose captures based on this high level information before XCON > etc is established. However I think the main point is that we need > to be a little more detailed when we describe the use of these > fields if people are even now proposing different uses. > > Regards, Christian > > > On 30/07/2012 11:46 PM, Espen Berger (espeberg) wrote: > > Hi Christian > > If a consumer want to learn about information that's on the > level of " like "Teleconference Room 2, Beijing" I think its > natural to look into conference event package or XCON. > > In the medical case the description attribute will have values > like "x-ray" or "CT-scan", "Operation", which is needed since > other captures attributes will have the same values. > > -Espen > > > -----Original Message----- > From: clue-bounces@ietf.org > [mailto:clue-bounces@ietf.org ] > On Behalf Of Christian Groves > Sent: 27. juli 2012 06:42 > To: clue@ietf.org > Subject: Re: [clue] FW: New Version Notification for > draft-xiao-clue-telemedical-use-case-00.txt > > Hello Paul, > > I think have a enumeration for very specific capabilities woul > dbe hard but I think there may be some common ones to many > conferencing / telepresence scenarios. In the discussion of > this topic I think that perhaps the "description" attribute we > have today may be too broad. I was thinking it would be used > for something like "Teleconference Room 2, Beijing" but it > seems there's proposals to use this for functional level > things like "speaker etc". > > Regards, Christian > > On 26/07/2012 11:28 PM, Paul Kyzivat wrote: > > [as individual] > > On 7/26/12 2:51 AM, Xiaojing wrote: > > Hi Espen, > > Please see my response inline. > > Regards, > Lennard > > -----Original Message----- > From: Espen Berger (espeberg) > [mailto:espeberg@cisco.com ] > Sent: Wednesday, July 25, 2012 11:19 PM > To: Xiaojing; clue@ietf.org > Subject: RE: [clue] FW: New Version Notification for > draft-xiao-clue-telemedical-use-case-00.txt > > Thanks for sharing the use case. I had a similar use > case in mind, > advanced lecture type calls mainly focusing on P2P > with multiple > presentation streams. > > My assumption for an advanced use case like this is > each capture has > at least a description field, e.g. 'x-ray' or > 'CT-scan', that can be > used by a manual operator to start and stop what to > receive. This use > case explains why we need descriptions for both > capture-scenes and > captures. > > [Xiao Jing] I share the same thinking on the > description field with > you. The different presentations need to be identified > from each > other. A straightforward way is to add description > tags to them. > > I think a textual description is the place to start. > It would be hard to start defining a machine-processable > enumeration > of application-specific categories. > > We already have the proposal for such a mechanism. > This use case simply reinforces the need for that mechanism. > > Questions > * Do you assume manual or automatic selection of > presentation streams? > [Xiao Jing] In my initial thinking, in the use case it > is the surgeon > and endpoint users who decide which presentation > streams to be sent > and displayed. Thus it is necessary to identify the > presentations. > * How do you decide which presentation streams are > important? What if > you offer three presentation streams and I can only > receive one, how > do I decide which of them to receive? > [Xiao Jing] I assume that the users can differentiate > the streams and > then decide which to receive. In this case, if the > user knows exactly > what the stream is about, he can decide without additional > information from the provider. But I also think we can > introduced > kind of priority concept into it. The "content" > attribute could be a > good place to include this idea. In my memory, > Christian and Paul are > working on this issue, and I'll try to inform them to > take this into > consideration. > * Have you identified additional meta-information to > the CLUE > framework needed to describe the information you have > in mind writing > up the use case. > [Xiao Jing] In this early stage, I'm just trying to > draw concern > about the necessity of having multiple presentation > streams. I think > the current framework can cover all the new > requirements coming up > with this use case at ease. > > I'm not sure whether 'priority' has been brought up on > this public > list or not. > > But it is my thought that we need a numeric priority value per > capture, that can be used by the recipient when it doesn't > have the > resources to render even the smallest entry from each > scene. *That* > would provide a way for the receiving equipment to provide > a default > rendering. Some endpoints might also provide a gui for the > end users > to manually configure based on descriptions. > > The numeric priority could be used to indicate that the > presentation > is more important than the speaker, or visa versa. And it > can be used > to indicate a relative priority among presentations. Etc. > > Thanks, > Paul > > Regards > > -Espen > > > -----Original Message----- > From: clue-bounces@ietf.org > > [mailto:clue-bounces@ietf.org > ] On Behalf > Of Xiaojing > Sent: 25. juli 2012 04:40 > To: clue@ietf.org > Subject: [clue] FW: New Version Notification for > draft-xiao-clue-telemedical-use-case-00.txt > > Hi all, > > I've submitted a telemedical use case, which addresses > the use of > Telepresence into medical scenarios. > > I think this use case is valid to add another > application field where > Telepresence can be used. > So I'd like to suggest adding this use case into the > current use case > document. > > Also, along with this use case, some new requirements > might come up, > e.g. the requirement to support multiple presentation > streams, which > might be considered into the requirement draft. > > Best regards, > Lennard > > -----Original Message----- > From: internet-drafts@ietf.org > > [mailto:internet-drafts@ietf.org > ] > Sent: Monday, July 09, 2012 11:13 AM > To: Xiaojing > Cc: Roni even > Subject: New Version Notification for > draft-xiao-clue-telemedical-use-case-00.txt > > > A new version of I-D, > draft-xiao-clue-telemedical-use-case-00.txt > has been successfully submitted by Lennard Xiao and > posted to the > IETF repository. > > Filename: draft-xiao-clue-telemedical-use-case > Revision: 00 > Title: Use Case for Telemedical with Multi-streams > Creation date: 2012-07-06 > WG ID: Individual Submission > Number of pages: 5 > URL: > http://www.ietf.org/internet-drafts/draft-xiao-clue-telemedical-use-c > ase-00.txt > Status: > http://datatracker.ietf.org/doc/draft-xiao-clue-telemedical-use-case > Htmlized: > http://tools.ietf.org/html/draft-xiao-clue-telemedical-use-case-00 > > > Abstract: > This memo presenst a telemedicine use case where > multiple > presentation streams are used for conveying > different information in > parallel to the main video from the surgery room > > > > > 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 > > _______________________________________________ > 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 Wed Aug 8 07:13: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 3B1D621F85CD for ; Wed, 8 Aug 2012 07:13:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.292 X-Spam-Level: X-Spam-Status: No, score=-2.292 tagged_above=-999 required=5 tests=[AWL=0.307, 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 K8I3+dsA677O for ; Wed, 8 Aug 2012 07:13:03 -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 3B02A11E808E for ; Wed, 8 Aug 2012 07:13:02 -0700 (PDT) Received: from omta11.westchester.pa.mail.comcast.net ([76.96.62.36]) by qmta04.westchester.pa.mail.comcast.net with comcast id kAvl1j0030mv7h054ECzKb; Wed, 08 Aug 2012 14:12:59 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta11.westchester.pa.mail.comcast.net with comcast id kECs1j00d3ZTu2S3XECsvJ; Wed, 08 Aug 2012 14:12:52 +0000 Message-ID: <502273E7.6040205@alum.mit.edu> Date: Wed, 08 Aug 2012 07:12:55 -0700 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: <8A527E21B95EF842BC0E952D6E82297747DA1D4A@szxeml527-mbx.china.huawei.com> <8A527E21B95EF842BC0E952D6E82297747DA1F8A@szxeml527-mbx.china.huawei.com> <50114600.3050406@alum.mit.edu> <50121C0B.5080100@nteczone.com> <50174FEE.1080208@nteczone.com> <5021FCC7.6070304@nteczone.com> In-Reply-To: <5021FCC7.6070304@nteczone.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] FW: New Version Notification for draft-xiao-clue-telemedical-use-case-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: Wed, 08 Aug 2012 14:13:05 -0000 On 8/7/12 10:44 PM, Christian Groves wrote: > Hello Mary, > > I guess the reason why is the same reason why the media streams will > likely be set up after CLUE. There could be potentially a large possible > set of captures/configurations that you want to narrow down before you > start assigning resources to them. You want to have enough information > associated with the captures so that an educated decision can be made > about whether to accept/use one. I don't think its enough just to assume > that XCON will handle these things. I'm not sure I understand this. ISTM that the initial INVITE to set up a CLUE call could contain an offer of: - an initial audio and video stream - a CLUE protocol stream - a bfcp stream - indication of support for the conf event package As soon as the initial answer is sent, if not sooner, the CLUE stream and the bfcp stream can be opened, and a subscribe sent for the conf event package. Shortly thereafter, CLUE advertisements can be sent in both directions and a first notification for the conf event package can be sent. Then, both the advertisement and the conf event state can be used for constructing the CLUE configuration message. Maybe we should create an enhanced call flow that shows all of that. Thanks, Paul > Regards, Christian > > On 2/08/2012 3:48 AM, Mary Barnes wrote: >> (As an individual) >> >> Why is it that you think XCON signaling with come after initial CLUE >> signaling? It is certainly possible to get an XCON notification before >> doing any CLUE signaling. CLUE will be reusing existing signaling >> protocols to establish the basic session - that would include using >> basic SIP conferencing and could include the use of XCON. >> >> Mary. >> >> On Mon, Jul 30, 2012 at 10:24 PM, Christian Groves >> > >> wrote: >> >> Hello Espen, >> >> The issue that I see is that the conference event package or XCON >> would come after the initial CLUE signalling. You may want to >> chose captures based on this high level information before XCON >> etc is established. However I think the main point is that we need >> to be a little more detailed when we describe the use of these >> fields if people are even now proposing different uses. >> >> Regards, Christian >> >> >> On 30/07/2012 11:46 PM, Espen Berger (espeberg) wrote: >> >> Hi Christian >> >> If a consumer want to learn about information that's on the >> level of " like "Teleconference Room 2, Beijing" I think its >> natural to look into conference event package or XCON. >> >> In the medical case the description attribute will have values >> like "x-ray" or "CT-scan", "Operation", which is needed since >> other captures attributes will have the same values. >> >> -Espen >> >> >> -----Original Message----- >> From: clue-bounces@ietf.org >> [mailto:clue-bounces@ietf.org ] >> On Behalf Of Christian Groves >> Sent: 27. juli 2012 06:42 >> To: clue@ietf.org >> Subject: Re: [clue] FW: New Version Notification for >> draft-xiao-clue-telemedical-use-case-00.txt >> >> Hello Paul, >> >> I think have a enumeration for very specific capabilities woul >> dbe hard but I think there may be some common ones to many >> conferencing / telepresence scenarios. In the discussion of >> this topic I think that perhaps the "description" attribute we >> have today may be too broad. I was thinking it would be used >> for something like "Teleconference Room 2, Beijing" but it >> seems there's proposals to use this for functional level >> things like "speaker etc". >> >> Regards, Christian >> >> On 26/07/2012 11:28 PM, Paul Kyzivat wrote: >> >> [as individual] >> >> On 7/26/12 2:51 AM, Xiaojing wrote: >> >> Hi Espen, >> >> Please see my response inline. >> >> Regards, >> Lennard >> >> -----Original Message----- >> From: Espen Berger (espeberg) >> [mailto:espeberg@cisco.com ] >> Sent: Wednesday, July 25, 2012 11:19 PM >> To: Xiaojing; clue@ietf.org >> Subject: RE: [clue] FW: New Version Notification for >> draft-xiao-clue-telemedical-use-case-00.txt >> >> Thanks for sharing the use case. I had a similar use >> case in mind, >> advanced lecture type calls mainly focusing on P2P >> with multiple >> presentation streams. >> >> My assumption for an advanced use case like this is >> each capture has >> at least a description field, e.g. 'x-ray' or >> 'CT-scan', that can be >> used by a manual operator to start and stop what to >> receive. This use >> case explains why we need descriptions for both >> capture-scenes and >> captures. >> >> [Xiao Jing] I share the same thinking on the >> description field with >> you. The different presentations need to be identified >> from each >> other. A straightforward way is to add description >> tags to them. >> >> I think a textual description is the place to start. >> It would be hard to start defining a machine-processable >> enumeration >> of application-specific categories. >> >> We already have the proposal for such a mechanism. >> This use case simply reinforces the need for that mechanism. >> >> Questions >> * Do you assume manual or automatic selection of >> presentation streams? >> [Xiao Jing] In my initial thinking, in the use case it >> is the surgeon >> and endpoint users who decide which presentation >> streams to be sent >> and displayed. Thus it is necessary to identify the >> presentations. >> * How do you decide which presentation streams are >> important? What if >> you offer three presentation streams and I can only >> receive one, how >> do I decide which of them to receive? >> [Xiao Jing] I assume that the users can differentiate >> the streams and >> then decide which to receive. In this case, if the >> user knows exactly >> what the stream is about, he can decide without additional >> information from the provider. But I also think we can >> introduced >> kind of priority concept into it. The "content" >> attribute could be a >> good place to include this idea. In my memory, >> Christian and Paul are >> working on this issue, and I'll try to inform them to >> take this into >> consideration. >> * Have you identified additional meta-information to >> the CLUE >> framework needed to describe the information you have >> in mind writing >> up the use case. >> [Xiao Jing] In this early stage, I'm just trying to >> draw concern >> about the necessity of having multiple presentation >> streams. I think >> the current framework can cover all the new >> requirements coming up >> with this use case at ease. >> >> I'm not sure whether 'priority' has been brought up on >> this public >> list or not. >> >> But it is my thought that we need a numeric priority value per >> capture, that can be used by the recipient when it doesn't >> have the >> resources to render even the smallest entry from each >> scene. *That* >> would provide a way for the receiving equipment to provide >> a default >> rendering. Some endpoints might also provide a gui for the >> end users >> to manually configure based on descriptions. >> >> The numeric priority could be used to indicate that the >> presentation >> is more important than the speaker, or visa versa. And it >> can be used >> to indicate a relative priority among presentations. Etc. >> >> Thanks, >> Paul >> >> Regards >> >> -Espen >> >> >> -----Original Message----- >> From: clue-bounces@ietf.org >> >> [mailto:clue-bounces@ietf.org >> ] On Behalf >> Of Xiaojing >> Sent: 25. juli 2012 04:40 >> To: clue@ietf.org >> Subject: [clue] FW: New Version Notification for >> draft-xiao-clue-telemedical-use-case-00.txt >> >> Hi all, >> >> I've submitted a telemedical use case, which addresses >> the use of >> Telepresence into medical scenarios. >> >> I think this use case is valid to add another >> application field where >> Telepresence can be used. >> So I'd like to suggest adding this use case into the >> current use case >> document. >> >> Also, along with this use case, some new requirements >> might come up, >> e.g. the requirement to support multiple presentation >> streams, which >> might be considered into the requirement draft. >> >> Best regards, >> Lennard >> >> -----Original Message----- >> From: internet-drafts@ietf.org >> >> [mailto:internet-drafts@ietf.org >> ] >> Sent: Monday, July 09, 2012 11:13 AM >> To: Xiaojing >> Cc: Roni even >> Subject: New Version Notification for >> draft-xiao-clue-telemedical-use-case-00.txt >> >> >> A new version of I-D, >> draft-xiao-clue-telemedical-use-case-00.txt >> has been successfully submitted by Lennard Xiao and >> posted to the >> IETF repository. >> >> Filename: draft-xiao-clue-telemedical-use-case >> Revision: 00 >> Title: Use Case for Telemedical with Multi-streams >> Creation date: 2012-07-06 >> WG ID: Individual Submission >> Number of pages: 5 >> URL: >> http://www.ietf.org/internet-drafts/draft-xiao-clue-telemedical-use-c >> ase-00.txt >> Status: >> http://datatracker.ietf.org/doc/draft-xiao-clue-telemedical-use-case >> Htmlized: >> http://tools.ietf.org/html/draft-xiao-clue-telemedical-use-case-00 >> >> >> Abstract: >> This memo presenst a telemedicine use case where >> multiple >> presentation streams are used for conveying >> different information in >> parallel to the main video from the surgery room >> >> >> >> >> 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 >> >> _______________________________________________ >> 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 Wed Aug 8 18:10:03 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 0591111E8161 for ; Wed, 8 Aug 2012 18:10:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.497 X-Spam-Level: X-Spam-Status: No, score=-2.497 tagged_above=-999 required=5 tests=[AWL=0.102, 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 P-xo3QFTV65r for ; Wed, 8 Aug 2012 18:10:01 -0700 (PDT) Received: from ipmail05.adl6.internode.on.net (ipmail05.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:5]) by ietfa.amsl.com (Postfix) with ESMTP id 6DF1511E80FF for ; Wed, 8 Aug 2012 18:09:58 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBAAENI1B20Xu7/2dsb2JhbAANLgq9CgEBAQMBAQEBNRsVBgYBAgENBAsRBAEBAQkDEwgHCQMCAQIBFR8IAQgTBgIBAQWHfhGnWZQHixIKBoZQA5ZdkWw Received: from ppp118-209-123-187.lns20.mel4.internode.on.net (HELO [127.0.0.1]) ([118.209.123.187]) by ipmail05.adl6.internode.on.net with ESMTP; 09 Aug 2012 10:39:55 +0930 Message-ID: <50230DDC.1020808@nteczone.com> Date: Thu, 09 Aug 2012 11:09:48 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: clue@ietf.org References: <8A527E21B95EF842BC0E952D6E82297747DA1D4A@szxeml527-mbx.china.huawei.com> <8A527E21B95EF842BC0E952D6E82297747DA1F8A@szxeml527-mbx.china.huawei.com> <50114600.3050406@alum.mit.edu> <50121C0B.5080100@nteczone.com> <50174FEE.1080208@nteczone.com> <5021FCC7.6070304@nteczone.com> <502273E7.6040205@alum.mit.edu> In-Reply-To: <502273E7.6040205@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] FW: New Version Notification for draft-xiao-clue-telemedical-use-case-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, 09 Aug 2012 01:10:03 -0000 Hello Paul, I think those enhanced call flows are necessary. I think we need to understand how the XCON concepts will map to those we've created in CLUE. I agree an initial invite can establish a CLUE and BFCP stream and conference event package but there are dependencies between the data that will be sent across them, i.e. an end point will use some data from one protocol to send data in another, i.e. the media information in XCON would be dependent on what captures were agreed via CLUE. So whilst they can be established at the same time there is actually some sequencing needed. AFAIK currently in XCON there is no concept of captures, so no ability to describe them. So coming back to the example to the issue below. If we believe that for a description of the endpoint that XCON should be used rather than our CLUE description "Attribute" we should state this in the CLUE framework draft as an aid to interoperability (although I'm not sure how labelling in multiple languages would work?), do we use or or? Regards, Christian On 9/08/2012 12:12 AM, Paul Kyzivat wrote: > On 8/7/12 10:44 PM, Christian Groves wrote: >> Hello Mary, >> >> I guess the reason why is the same reason why the media streams will >> likely be set up after CLUE. There could be potentially a large possible >> set of captures/configurations that you want to narrow down before you >> start assigning resources to them. You want to have enough information >> associated with the captures so that an educated decision can be made >> about whether to accept/use one. I don't think its enough just to assume >> that XCON will handle these things. > > I'm not sure I understand this. > > ISTM that the initial INVITE to set up a CLUE call could contain an > offer of: > - an initial audio and video stream > - a CLUE protocol stream > - a bfcp stream > - indication of support for the conf event package > > As soon as the initial answer is sent, if not sooner, the CLUE stream > and the bfcp stream can be opened, and a subscribe sent for the conf > event package. Shortly thereafter, CLUE advertisements can be sent in > both directions and a first notification for the conf event package > can be sent. > > Then, both the advertisement and the conf event state can be used for > constructing the CLUE configuration message. > > Maybe we should create an enhanced call flow that shows all of that. > > Thanks, > Paul > >> Regards, Christian >> >> On 2/08/2012 3:48 AM, Mary Barnes wrote: >>> (As an individual) >>> >>> Why is it that you think XCON signaling with come after initial CLUE >>> signaling? It is certainly possible to get an XCON notification before >>> doing any CLUE signaling. CLUE will be reusing existing signaling >>> protocols to establish the basic session - that would include using >>> basic SIP conferencing and could include the use of XCON. >>> >>> Mary. >>> >>> On Mon, Jul 30, 2012 at 10:24 PM, Christian Groves >>> > >>> wrote: >>> >>> Hello Espen, >>> >>> The issue that I see is that the conference event package or XCON >>> would come after the initial CLUE signalling. You may want to >>> chose captures based on this high level information before XCON >>> etc is established. However I think the main point is that we need >>> to be a little more detailed when we describe the use of these >>> fields if people are even now proposing different uses. >>> >>> Regards, Christian >>> >>> >>> On 30/07/2012 11:46 PM, Espen Berger (espeberg) wrote: >>> >>> Hi Christian >>> >>> If a consumer want to learn about information that's on the >>> level of " like "Teleconference Room 2, Beijing" I think its >>> natural to look into conference event package or XCON. >>> >>> In the medical case the description attribute will have values >>> like "x-ray" or "CT-scan", "Operation", which is needed since >>> other captures attributes will have the same values. >>> >>> -Espen >>> >>> >>> -----Original Message----- >>> From: clue-bounces@ietf.org >>> [mailto:clue-bounces@ietf.org ] >>> On Behalf Of Christian Groves >>> Sent: 27. juli 2012 06:42 >>> To: clue@ietf.org >>> Subject: Re: [clue] FW: New Version Notification for >>> draft-xiao-clue-telemedical-use-case-00.txt >>> >>> Hello Paul, >>> >>> I think have a enumeration for very specific capabilities woul >>> dbe hard but I think there may be some common ones to many >>> conferencing / telepresence scenarios. In the discussion of >>> this topic I think that perhaps the "description" attribute we >>> have today may be too broad. I was thinking it would be used >>> for something like "Teleconference Room 2, Beijing" but it >>> seems there's proposals to use this for functional level >>> things like "speaker etc". >>> >>> Regards, Christian >>> >>> On 26/07/2012 11:28 PM, Paul Kyzivat wrote: >>> >>> [as individual] >>> >>> On 7/26/12 2:51 AM, Xiaojing wrote: >>> >>> Hi Espen, >>> >>> Please see my response inline. >>> >>> Regards, >>> Lennard >>> >>> -----Original Message----- >>> From: Espen Berger (espeberg) >>> [mailto:espeberg@cisco.com ] >>> Sent: Wednesday, July 25, 2012 11:19 PM >>> To: Xiaojing; clue@ietf.org >>> Subject: RE: [clue] FW: New Version Notification for >>> draft-xiao-clue-telemedical-use-case-00.txt >>> >>> Thanks for sharing the use case. I had a similar use >>> case in mind, >>> advanced lecture type calls mainly focusing on P2P >>> with multiple >>> presentation streams. >>> >>> My assumption for an advanced use case like this is >>> each capture has >>> at least a description field, e.g. 'x-ray' or >>> 'CT-scan', that can be >>> used by a manual operator to start and stop what to >>> receive. This use >>> case explains why we need descriptions for both >>> capture-scenes and >>> captures. >>> >>> [Xiao Jing] I share the same thinking on the >>> description field with >>> you. The different presentations need to be identified >>> from each >>> other. A straightforward way is to add description >>> tags to them. >>> >>> I think a textual description is the place to start. >>> It would be hard to start defining a machine-processable >>> enumeration >>> of application-specific categories. >>> >>> We already have the proposal for such a mechanism. >>> This use case simply reinforces the need for that mechanism. >>> >>> Questions >>> * Do you assume manual or automatic selection of >>> presentation streams? >>> [Xiao Jing] In my initial thinking, in the use case it >>> is the surgeon >>> and endpoint users who decide which presentation >>> streams to be sent >>> and displayed. Thus it is necessary to identify the >>> presentations. >>> * How do you decide which presentation streams are >>> important? What if >>> you offer three presentation streams and I can only >>> receive one, how >>> do I decide which of them to receive? >>> [Xiao Jing] I assume that the users can differentiate >>> the streams and >>> then decide which to receive. In this case, if the >>> user knows exactly >>> what the stream is about, he can decide without additional >>> information from the provider. But I also think we can >>> introduced >>> kind of priority concept into it. The "content" >>> attribute could be a >>> good place to include this idea. In my memory, >>> Christian and Paul are >>> working on this issue, and I'll try to inform them to >>> take this into >>> consideration. >>> * Have you identified additional meta-information to >>> the CLUE >>> framework needed to describe the information you have >>> in mind writing >>> up the use case. >>> [Xiao Jing] In this early stage, I'm just trying to >>> draw concern >>> about the necessity of having multiple presentation >>> streams. I think >>> the current framework can cover all the new >>> requirements coming up >>> with this use case at ease. >>> >>> I'm not sure whether 'priority' has been brought up on >>> this public >>> list or not. >>> >>> But it is my thought that we need a numeric priority value per >>> capture, that can be used by the recipient when it doesn't >>> have the >>> resources to render even the smallest entry from each >>> scene. *That* >>> would provide a way for the receiving equipment to provide >>> a default >>> rendering. Some endpoints might also provide a gui for the >>> end users >>> to manually configure based on descriptions. >>> >>> The numeric priority could be used to indicate that the >>> presentation >>> is more important than the speaker, or visa versa. And it >>> can be used >>> to indicate a relative priority among presentations. Etc. >>> >>> Thanks, >>> Paul >>> >>> Regards >>> >>> -Espen >>> >>> >>> -----Original Message----- >>> From: clue-bounces@ietf.org >>> >>> [mailto:clue-bounces@ietf.org >>> ] On Behalf >>> Of Xiaojing >>> Sent: 25. juli 2012 04:40 >>> To: clue@ietf.org >>> Subject: [clue] FW: New Version Notification for >>> draft-xiao-clue-telemedical-use-case-00.txt >>> >>> Hi all, >>> >>> I've submitted a telemedical use case, which addresses >>> the use of >>> Telepresence into medical scenarios. >>> >>> I think this use case is valid to add another >>> application field where >>> Telepresence can be used. >>> So I'd like to suggest adding this use case into the >>> current use case >>> document. >>> >>> Also, along with this use case, some new requirements >>> might come up, >>> e.g. the requirement to support multiple presentation >>> streams, which >>> might be considered into the requirement draft. >>> >>> Best regards, >>> Lennard >>> >>> -----Original Message----- >>> From: internet-drafts@ietf.org >>> >>> [mailto:internet-drafts@ietf.org >>> ] >>> Sent: Monday, July 09, 2012 11:13 AM >>> To: Xiaojing >>> Cc: Roni even >>> Subject: New Version Notification for >>> draft-xiao-clue-telemedical-use-case-00.txt >>> >>> >>> A new version of I-D, >>> draft-xiao-clue-telemedical-use-case-00.txt >>> has been successfully submitted by Lennard Xiao and >>> posted to the >>> IETF repository. >>> >>> Filename: draft-xiao-clue-telemedical-use-case >>> Revision: 00 >>> Title: Use Case for Telemedical with Multi-streams >>> Creation date: 2012-07-06 >>> WG ID: Individual Submission >>> Number of pages: 5 >>> URL: >>> http://www.ietf.org/internet-drafts/draft-xiao-clue-telemedical-use-c >>> ase-00.txt >>> Status: >>> http://datatracker.ietf.org/doc/draft-xiao-clue-telemedical-use-case >>> Htmlized: >>> http://tools.ietf.org/html/draft-xiao-clue-telemedical-use-case-00 >>> >>> >>> Abstract: >>> This memo presenst a telemedicine use case where >>> multiple >>> presentation streams are used for conveying >>> different information in >>> parallel to the main video from the surgery room >>> >>> >>> >>> >>> 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 >>> >>> _______________________________________________ >>> 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 Aug 9 11:06: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 F01A721F86FC for ; Thu, 9 Aug 2012 11:06:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.524 X-Spam-Level: X-Spam-Status: No, score=-103.524 tagged_above=-999 required=5 tests=[AWL=0.074, 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 9BlF1QX+KvYz for ; Thu, 9 Aug 2012 11:06:46 -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 9764521F86DE for ; Thu, 9 Aug 2012 11:06:45 -0700 (PDT) Received: by lahm15 with SMTP id m15so436460lah.31 for ; Thu, 09 Aug 2012 11:06:44 -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=aaxsTPIQtv0n+UHvNggAqF9S3Y6q8EHf+1S8SoA698k=; b=FfGTFezK8YtPMp44hERbDGKQpls34e9fXf0TrTms/25HmSh6kjuLrfxrdzLMjOrDuX 2XfMNsM7l6az7ccfLAFmZ0aJxYGq6jb2k+rPgZB+6UCofZXye7fUfkrrFuTyTeXZe9lp 7mY44edvCM7YVsYJnKC7BDT06vrbKMMDgxEQ8gf7SGbEqcghagMymOPXeaqyB5vQcgwF G3d69VYg8QNFhY66g62U7T6RuLHGc0txB0eGyCScjfrXfaEl0RswNTMThV2sk9OEQyLq ePF16ZafBP/zTvDXB4sKb5ifkPFx3HlQm16wB+7ex73RctVZSGJcDAScYm87vWdYjyRJ LBzA== MIME-Version: 1.0 Received: by 10.152.131.37 with SMTP id oj5mr194662lab.14.1344535604544; Thu, 09 Aug 2012 11:06:44 -0700 (PDT) Received: by 10.112.85.196 with HTTP; Thu, 9 Aug 2012 11:06:44 -0700 (PDT) In-Reply-To: References: Date: Thu, 9 Aug 2012 13:06:44 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=f46d042c6b8d18c57f04c6d91718 Subject: Re: [clue] CLUE WG Interim Meeting (Sept. 2012) Doodle 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, 09 Aug 2012 18:06:47 -0000 --f46d042c6b8d18c57f04c6d91718 Content-Type: text/plain; charset=ISO-8859-1 Hi all, We now have a quorum for the meeting. Wednesday and Thursday (Sept. 19th-20th, 2012) work best for the majority of participants. The meeting will be held in the San Jose/Santa Clara, CA area. We will announce further details as soon as they are available. Regards, Mary. On Thu, Aug 2, 2012 at 8:08 AM, Mary Barnes wrote: > I have modified the doodle and removed the 18th as I have been informed > that won't work for some key folks. So, the options now are 19-20, 20-21. > > Please fill out the doodle by Friday, August 10th, so we can get a host > confirmed for the dates. > > Thanks, > Mary. > > > On Wed, Aug 1, 2012 at 8:33 PM, Mary Barnes wrote: > >> Hi all, >> >> As noted in the WG session today, we are planning a CLUE WG interim >> meeting for mid September (week of 17th). Please indicate your >> availability for Sept. 18-21. We will select two sequential days (i.e., >> 18-19, 19-20, 20-21) >> >> http://www.doodle.com/uzb9nf2h92dqfp5i >> >> We have a few people that are looking into the possibility of hosting in >> San Jose. >> >> Note that the focus of this interim is to work out details for the >> solution. For this meeting to be effective, we need new and updated drafts >> addressing the problem space categories in the summary slides, which I have >> uploaded the meeting materials manager: >> Chairs - agenda & way forward (Wednesday) >> We will set a draft deadline of one week before the meeting. >> >> Regards, >> Mary. >> > > --f46d042c6b8d18c57f04c6d91718 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all,

We now have a quorum for the meeting. =A0Wednesd= ay and Thursday (Sept. 19th-20th, 2012) work best for the majority of parti= cipants. =A0The meeting will be held in the San Jose/Santa Clara, CA area. = =A0 We will announce further details as soon as they are available. =A0

Regards,
Mary.=A0

On Thu, Aug 2, 2012 at 8:08 AM, Mary Barnes <mary.ietf.bar= nes@gmail.com> wrote:
I have modified the doodle and removed the 1= 8th as I have been informed that won't work for some key folks. So, the= options now are 19-20, 20-21.

Please fill out the doodle by Friday, August 10th, so we can= get a host confirmed for the dates.

Thanks,
Mary.


<= div class=3D"gmail_quote">On Wed, Aug 1, 2012 at 8:33 PM, Mary Barnes <mary.ietf.barnes@gmail.com> wrote:
Hi all,

As noted in the W= G session today, we are planning a CLUE WG interim meeting for mid Septembe= r (week of 17th). =A0 Please indicate your availability for Sept. 18-21. = =A0We will select two sequential days (i.e., 18-19, 19-20, 20-21)


We have a few people that are looking into the possibility of hostin= g in San Jose. =A0

Note that the focus of this interim is to work out deta= ils for the solution. =A0For this meeting to be effective, we need new and = updated drafts addressing the problem space categories in the summary slide= s, which I have uploaded the meeting materials manager:
Chairs - agenda & way forward (Wednesday)<= /div>
We will set a draft deadline of one week before the meeting.=A0

Regards,
Mary.=A0


--f46d042c6b8d18c57f04c6d91718-- From pkyzivat@alum.mit.edu Thu Aug 9 14:10: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 37B3B21F860F for ; Thu, 9 Aug 2012 14:10:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.222 X-Spam-Level: X-Spam-Status: No, score=-1.222 tagged_above=-999 required=5 tests=[AWL=-0.785, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.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 BzNap0POcE6x for ; Thu, 9 Aug 2012 14:10:53 -0700 (PDT) Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:24]) by ietfa.amsl.com (Postfix) with ESMTP id 38BAE21F8608 for ; Thu, 9 Aug 2012 14:10:52 -0700 (PDT) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta02.westchester.pa.mail.comcast.net with comcast id kfGB1j01C1ZXKqc51lAufB; Thu, 09 Aug 2012 21:10:54 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta21.westchester.pa.mail.comcast.net with comcast id klBR1j00B3ZTu2S3hlBRkt; Thu, 09 Aug 2012 21:11:25 +0000 Message-ID: <50242759.6010909@alum.mit.edu> Date: Thu, 09 Aug 2012 14:10:49 -0700 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: <8A527E21B95EF842BC0E952D6E82297747DA1D4A@szxeml527-mbx.china.huawei.com> <8A527E21B95EF842BC0E952D6E82297747DA1F8A@szxeml527-mbx.china.huawei.com> <50114600.3050406@alum.mit.edu> <50121C0B.5080100@nteczone.com> <50174FEE.1080208@nteczone.com> <5021FCC7.6070304@nteczone.com> <502273E7.6040205@alum.mit.edu> <50230DDC.1020808@nteczone.com> In-Reply-To: <50230DDC.1020808@nteczone.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] FW: New Version Notification for draft-xiao-clue-telemedical-use-case-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, 09 Aug 2012 21:10:54 -0000 On 8/8/12 6:09 PM, Christian Groves wrote: > Hello Paul, > > I think those enhanced call flows are necessary. What do others think? Shall we ask that the call flows (at least some of them) include conference event package subscription and notifications and bfcp setup and signaling? I agree that this may be necessary - probably not in every call flow, but in cases where the use of those channels is necessary for the use case to work. And how often that is depends on how much information we defer to those protocols for. > I think we need to > understand how the XCON concepts will map to those we've created in > CLUE. I agree an initial invite can establish a CLUE and BFCP stream and > conference event package but there are dependencies between the data > that will be sent across them, i.e. an end point will use some data from > one protocol to send data in another, i.e. the media information in XCON > would be dependent on what captures were agreed via CLUE. So whilst they > can be established at the same time there is actually some sequencing > needed. AFAIK currently in XCON there is no concept of captures, so no > ability to describe them. > > So coming back to the example to the issue below. If we believe that for > a description of the endpoint that XCON should be used rather than our > CLUE description "Attribute" we should state this in the CLUE framework > draft as an aid to interoperability (although I'm not sure how labelling > in multiple languages would work?), do we use or > or? > > Regards, Christian Thanks, Paul > On 9/08/2012 12:12 AM, Paul Kyzivat wrote: >> On 8/7/12 10:44 PM, Christian Groves wrote: >>> Hello Mary, >>> >>> I guess the reason why is the same reason why the media streams will >>> likely be set up after CLUE. There could be potentially a large possible >>> set of captures/configurations that you want to narrow down before you >>> start assigning resources to them. You want to have enough information >>> associated with the captures so that an educated decision can be made >>> about whether to accept/use one. I don't think its enough just to assume >>> that XCON will handle these things. >> >> I'm not sure I understand this. >> >> ISTM that the initial INVITE to set up a CLUE call could contain an >> offer of: >> - an initial audio and video stream >> - a CLUE protocol stream >> - a bfcp stream >> - indication of support for the conf event package >> >> As soon as the initial answer is sent, if not sooner, the CLUE stream >> and the bfcp stream can be opened, and a subscribe sent for the conf >> event package. Shortly thereafter, CLUE advertisements can be sent in >> both directions and a first notification for the conf event package >> can be sent. >> >> Then, both the advertisement and the conf event state can be used for >> constructing the CLUE configuration message. >> >> Maybe we should create an enhanced call flow that shows all of that. >> >> Thanks, >> Paul >> >>> Regards, Christian >>> >>> On 2/08/2012 3:48 AM, Mary Barnes wrote: >>>> (As an individual) >>>> >>>> Why is it that you think XCON signaling with come after initial CLUE >>>> signaling? It is certainly possible to get an XCON notification before >>>> doing any CLUE signaling. CLUE will be reusing existing signaling >>>> protocols to establish the basic session - that would include using >>>> basic SIP conferencing and could include the use of XCON. >>>> >>>> Mary. >>>> >>>> On Mon, Jul 30, 2012 at 10:24 PM, Christian Groves >>>> > >>>> wrote: >>>> >>>> Hello Espen, >>>> >>>> The issue that I see is that the conference event package or XCON >>>> would come after the initial CLUE signalling. You may want to >>>> chose captures based on this high level information before XCON >>>> etc is established. However I think the main point is that we need >>>> to be a little more detailed when we describe the use of these >>>> fields if people are even now proposing different uses. >>>> >>>> Regards, Christian >>>> >>>> >>>> On 30/07/2012 11:46 PM, Espen Berger (espeberg) wrote: >>>> >>>> Hi Christian >>>> >>>> If a consumer want to learn about information that's on the >>>> level of " like "Teleconference Room 2, Beijing" I think its >>>> natural to look into conference event package or XCON. >>>> >>>> In the medical case the description attribute will have values >>>> like "x-ray" or "CT-scan", "Operation", which is needed since >>>> other captures attributes will have the same values. >>>> >>>> -Espen >>>> >>>> >>>> -----Original Message----- >>>> From: clue-bounces@ietf.org >>>> [mailto:clue-bounces@ietf.org ] >>>> On Behalf Of Christian Groves >>>> Sent: 27. juli 2012 06:42 >>>> To: clue@ietf.org >>>> Subject: Re: [clue] FW: New Version Notification for >>>> draft-xiao-clue-telemedical-use-case-00.txt >>>> >>>> Hello Paul, >>>> >>>> I think have a enumeration for very specific capabilities woul >>>> dbe hard but I think there may be some common ones to many >>>> conferencing / telepresence scenarios. In the discussion of >>>> this topic I think that perhaps the "description" attribute we >>>> have today may be too broad. I was thinking it would be used >>>> for something like "Teleconference Room 2, Beijing" but it >>>> seems there's proposals to use this for functional level >>>> things like "speaker etc". >>>> >>>> Regards, Christian >>>> >>>> On 26/07/2012 11:28 PM, Paul Kyzivat wrote: >>>> >>>> [as individual] >>>> >>>> On 7/26/12 2:51 AM, Xiaojing wrote: >>>> >>>> Hi Espen, >>>> >>>> Please see my response inline. >>>> >>>> Regards, >>>> Lennard >>>> >>>> -----Original Message----- >>>> From: Espen Berger (espeberg) >>>> [mailto:espeberg@cisco.com ] >>>> Sent: Wednesday, July 25, 2012 11:19 PM >>>> To: Xiaojing; clue@ietf.org >>>> Subject: RE: [clue] FW: New Version Notification for >>>> draft-xiao-clue-telemedical-use-case-00.txt >>>> >>>> Thanks for sharing the use case. I had a similar use >>>> case in mind, >>>> advanced lecture type calls mainly focusing on P2P >>>> with multiple >>>> presentation streams. >>>> >>>> My assumption for an advanced use case like this is >>>> each capture has >>>> at least a description field, e.g. 'x-ray' or >>>> 'CT-scan', that can be >>>> used by a manual operator to start and stop what to >>>> receive. This use >>>> case explains why we need descriptions for both >>>> capture-scenes and >>>> captures. >>>> >>>> [Xiao Jing] I share the same thinking on the >>>> description field with >>>> you. The different presentations need to be identified >>>> from each >>>> other. A straightforward way is to add description >>>> tags to them. >>>> >>>> I think a textual description is the place to start. >>>> It would be hard to start defining a machine-processable >>>> enumeration >>>> of application-specific categories. >>>> >>>> We already have the proposal for such a mechanism. >>>> This use case simply reinforces the need for that mechanism. >>>> >>>> Questions >>>> * Do you assume manual or automatic selection of >>>> presentation streams? >>>> [Xiao Jing] In my initial thinking, in the use case it >>>> is the surgeon >>>> and endpoint users who decide which presentation >>>> streams to be sent >>>> and displayed. Thus it is necessary to identify the >>>> presentations. >>>> * How do you decide which presentation streams are >>>> important? What if >>>> you offer three presentation streams and I can only >>>> receive one, how >>>> do I decide which of them to receive? >>>> [Xiao Jing] I assume that the users can differentiate >>>> the streams and >>>> then decide which to receive. In this case, if the >>>> user knows exactly >>>> what the stream is about, he can decide without additional >>>> information from the provider. But I also think we can >>>> introduced >>>> kind of priority concept into it. The "content" >>>> attribute could be a >>>> good place to include this idea. In my memory, >>>> Christian and Paul are >>>> working on this issue, and I'll try to inform them to >>>> take this into >>>> consideration. >>>> * Have you identified additional meta-information to >>>> the CLUE >>>> framework needed to describe the information you have >>>> in mind writing >>>> up the use case. >>>> [Xiao Jing] In this early stage, I'm just trying to >>>> draw concern >>>> about the necessity of having multiple presentation >>>> streams. I think >>>> the current framework can cover all the new >>>> requirements coming up >>>> with this use case at ease. >>>> >>>> I'm not sure whether 'priority' has been brought up on >>>> this public >>>> list or not. >>>> >>>> But it is my thought that we need a numeric priority value per >>>> capture, that can be used by the recipient when it doesn't >>>> have the >>>> resources to render even the smallest entry from each >>>> scene. *That* >>>> would provide a way for the receiving equipment to provide >>>> a default >>>> rendering. Some endpoints might also provide a gui for the >>>> end users >>>> to manually configure based on descriptions. >>>> >>>> The numeric priority could be used to indicate that the >>>> presentation >>>> is more important than the speaker, or visa versa. And it >>>> can be used >>>> to indicate a relative priority among presentations. Etc. >>>> >>>> Thanks, >>>> Paul >>>> >>>> Regards >>>> >>>> -Espen >>>> >>>> >>>> -----Original Message----- >>>> From: clue-bounces@ietf.org >>>> >>>> [mailto:clue-bounces@ietf.org >>>> ] On Behalf >>>> Of Xiaojing >>>> Sent: 25. juli 2012 04:40 >>>> To: clue@ietf.org >>>> Subject: [clue] FW: New Version Notification for >>>> draft-xiao-clue-telemedical-use-case-00.txt >>>> >>>> Hi all, >>>> >>>> I've submitted a telemedical use case, which addresses >>>> the use of >>>> Telepresence into medical scenarios. >>>> >>>> I think this use case is valid to add another >>>> application field where >>>> Telepresence can be used. >>>> So I'd like to suggest adding this use case into the >>>> current use case >>>> document. >>>> >>>> Also, along with this use case, some new requirements >>>> might come up, >>>> e.g. the requirement to support multiple presentation >>>> streams, which >>>> might be considered into the requirement draft. >>>> >>>> Best regards, >>>> Lennard >>>> >>>> -----Original Message----- >>>> From: internet-drafts@ietf.org >>>> >>>> [mailto:internet-drafts@ietf.org >>>> ] >>>> Sent: Monday, July 09, 2012 11:13 AM >>>> To: Xiaojing >>>> Cc: Roni even >>>> Subject: New Version Notification for >>>> draft-xiao-clue-telemedical-use-case-00.txt >>>> >>>> >>>> A new version of I-D, >>>> draft-xiao-clue-telemedical-use-case-00.txt >>>> has been successfully submitted by Lennard Xiao and >>>> posted to the >>>> IETF repository. >>>> >>>> Filename: draft-xiao-clue-telemedical-use-case >>>> Revision: 00 >>>> Title: Use Case for Telemedical with Multi-streams >>>> Creation date: 2012-07-06 >>>> WG ID: Individual Submission >>>> Number of pages: 5 >>>> URL: >>>> http://www.ietf.org/internet-drafts/draft-xiao-clue-telemedical-use-c >>>> ase-00.txt >>>> Status: >>>> http://datatracker.ietf.org/doc/draft-xiao-clue-telemedical-use-case >>>> Htmlized: >>>> http://tools.ietf.org/html/draft-xiao-clue-telemedical-use-case-00 >>>> >>>> >>>> Abstract: >>>> This memo presenst a telemedicine use case where >>>> multiple >>>> presentation streams are used for conveying >>>> different information in >>>> parallel to the main video from the surgery room >>>> >>>> >>>> >>>> >>>> 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 >>>> >>>> _______________________________________________ >>>> 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 mary.ietf.barnes@gmail.com Mon Aug 13 10:16: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 E20AE21F86F7 for ; Mon, 13 Aug 2012 10:16:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.526 X-Spam-Level: X-Spam-Status: No, score=-104.526 tagged_above=-999 required=5 tests=[AWL=1.072, BAYES_00=-2.599, GB_I_INVITATION=-2, 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 gw24bAyhEFcM for ; Mon, 13 Aug 2012 10:16:43 -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 9498721F85F3 for ; Mon, 13 Aug 2012 10:16:42 -0700 (PDT) Received: by lbbgg6 with SMTP id gg6so2276477lbb.31 for ; Mon, 13 Aug 2012 10:16: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; bh=/FHz8tZes4tklJfS88T6mopczF3Sv/k5GmOMF6G/isM=; b=PSe+aibOs7TdnKxcetDlOnrqmExC8RariRktyiaWFvCTZafrGjQarbdEJQ6XBIuiY+ LwP6swZIbdHG/ApMfesk/UuZX3ZKGn+1IfyRscrxP7eM1qcaGOm40OhLJ2C41oSNElX3 Wq8sMz6DoNH1DhNBbQWR9P5BH2KVkXZdhjF0kVckUq+R8DAVPXe68xDs+bOR77okCnmf +0qtPPEaY/xAGbYteq373Tycj0SLUYtPx3FZ09Ymy5ZFeihZ/JLSRXigy1lCDar5CcQI 27z9y0bLWi/XPGpXVu+yPwfGpBSAQry95v+9pUS2Hq9frTvmcsopYz6L0lXRd00NMYVO Chjg== MIME-Version: 1.0 Received: by 10.152.112.234 with SMTP id it10mr12570558lab.36.1344878201081; Mon, 13 Aug 2012 10:16:41 -0700 (PDT) Received: by 10.112.85.196 with HTTP; Mon, 13 Aug 2012 10:16:41 -0700 (PDT) In-Reply-To: <1759567490.52304.1344877849982.JavaMail.nobody@jva2tc002.webex.com> References: <1759567490.52304.1344877849982.JavaMail.nobody@jva2tc002.webex.com> Date: Mon, 13 Aug 2012 12:16:41 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=f46d04083919710e4b04c728db14 Subject: [clue] Meeting invitation: CLUE Design Team 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, 13 Aug 2012 17:16:44 -0000 --f46d04083919710e4b04c728db14 Content-Type: text/plain; charset=ISO-8859-1 Hi all, Below are the new Webex details for the design team meetings. I have updated the wiki as well with the info. We will shortly send the agenda for tomorrow's meeting. Mary. ---------- Forwarded message ---------- From: Clue Working Group Date: Mon, Aug 13, 2012 at 12:10 PM Subject: Meeting invitation: CLUE Design Team To: mary.ietf.barnes@gmail.com Hello , Clue Working Group invites you to attend this online meeting. Topic: CLUE Design Team Date: Every Tuesday, from Tuesday, August 14, 2012 to Tuesday, March 5, 2013 Time: 9:00 am, Central Daylight Time (Chicago, GMT-05:00) Meeting Number: 642 221 028 Meeting Password: 1234 ------------------------------------------------------- To join the online meeting (Now from mobile devices!) ------------------------------------------------------- 1. Go to https://ietf.webex.com/ietf/j.php?ED=158121817&UID=1265811087&PW=NNWRkOGVjYTBh&RT=MiM3 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=158121817&UID=1265811087&PW=NNWRkOGVjYTBh&ORT=MiM3 ------------------------------------------------------- To join the audio conference only ------------------------------------------------------- Call-in toll number (US/Canada): +1-408-600-3600 Access code:642 221 028 ------------------------------------------------------- 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=158121817&UID=1265811087&ICS=MI&LD=1&RD=2&ST=1&SHA2=4FrGfPfxs/xl-6c5Pe8ihqG6MdpD-MoF6oBsrw86TDE=&RT=MiM3 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:+14086003600x642221028# 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. --f46d04083919710e4b04c728db14 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all,

Below are the new Webex details for the design t= eam meetings. =A0I have updated the wiki as well with the info. =A0 We will= shortly send the agenda for tomorrow's meeting.

Mary.

---------- Forwarded message ------= ----
From: Clue Working Group <messenger@webex.com>
Date: Mon, Aug 13, 2012 at 12:10 PM
Subject: Meeting invitation: CLUE De= sign Team
To: mary.ietf.ba= rnes@gmail.com



Hello ,

Clue Working Group invites you to attend this online mee= ting.

Topic: CLUE Design Team
Date: Every Tuesday, from Tues= day, August 14, 2012 to Tuesday, March 5, 2013
Time: 9:00 am, Central = Daylight Time (Chicago, GMT-05:00)
Meeting Number: 642 221 028
Meeting Password: 1234


---= ----------------------------------------------------
To join the onlin= e meeting (Now from mobile devices!)
---------------------------------= ----------------------
1. Go to htt= ps://ietf.webex.com/ietf/j.php?ED=3D158121817&UID=3D1265811087&PW= =3DNNWRkOGVjYTBh&RT=3DMiM3
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 lin= k:
https://iet= f.webex.com/ietf/j.php?ED=3D158121817&UID=3D1265811087&PW=3DNNWRkOG= VjYTBh&ORT=3DMiM3

-------------------------------------------------------
To join = the audio conference only
--------------------------------------------= -----------
Call-in toll number (US/Canada): +1-408-600-3600

Access code:642 221 028

-----------------------------------= --------------------
For assistance
-----------------------------= --------------------------
1. Go to https://ietf.webex.com/ietf/mc
2. On the left navigation bar, click "Support".

You ca= n contact me at:
clue-chairs@tools.ietf.org


To add this meeti= ng to your calendar program (for example Microsoft Outlook), click this lin= k:
https:= //ietf.webex.com/ietf/j.php?ED=3D158121817&UID=3D1265811087&ICS=3DM= I&LD=3D1&RD=3D2&ST=3D1&SHA2=3D4FrGfPfxs/xl-6c5Pe8ihqG6MdpD-= MoF6oBsrw86TDE=3D&RT=3DMiM3

The playback of UCF (Universal Communications Format) rich media file= s requires appropriate players. To view this type of rich media files in th= e meeting, please check whether you have the players installed on your comp= uter 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://ww= w.webex.com

CCP:+14086003600x642221028#

IMPORTANT NOTICE: This WebEx se= rvice includes a feature that allows audio and any documents and other mate= rials exchanged or viewed during the session to be recorded. By joining thi= s session, you automatically consent to such recordings. If you do not cons= ent 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.

--f46d04083919710e4b04c728db14-- From trac+clue@trac.tools.ietf.org Mon Aug 13 12:20: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 7917921F858A for ; Mon, 13 Aug 2012 12:20: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 OLHwLOSNK1X0 for ; Mon, 13 Aug 2012 12:20:52 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id AA46A21F84F4 for ; Mon, 13 Aug 2012 12:20: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 1T10Bf-0001r9-VY; Mon, 13 Aug 2012 15:20:28 -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: Mon, 13 Aug 2012 19:20:27 -0000 X-URL: http://tools.ietf.org/wg/clue/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/clue/trac/ticket/5#comment:4 Message-ID: <078.7aa92c11998631ae01f712174f7445da@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: allyn@cisco.com, apeppere@gmail.com, bbaldino@cisco.com, mark.duckworth@polycom.com Resent-Message-Id: <20120813192052.AA46A21F84F4@ietfa.amsl.com> Resent-Date: Mon, 13 Aug 2012 12:20:52 -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: Mon, 13 Aug 2012 19:20:53 -0000 #5: Describing composed captures Changes (by mary.ietf.barnes@…): * status: new => closed * resolution: => fixed Comment: Ticket is being closed as the consensus is that a boolean attribute is sufficient. - Other protocols may be more appropriate for describing different aspects of composed captures - CLUE may be extended in future, if necessary, to provide more information or integrate with other protocols -- --------------------------------+------------------------------------------ Reporter: pkyzivat@… | Owner: draft-ietf-clue-framework@… Type: task | Status: closed Priority: major | Milestone: Component: framework | Version: Severity: Active WG Document | Resolution: fixed Keywords: | --------------------------------+------------------------------------------ Ticket URL: clue From trac+clue@trac.tools.ietf.org Mon Aug 13 12:24:03 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 6B2DF21F8628 for ; Mon, 13 Aug 2012 12:24:03 -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 q8gctuY7mJ4V for ; Mon, 13 Aug 2012 12:24:03 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id D70EB21F8627 for ; Mon, 13 Aug 2012 12:24:02 -0700 (PDT) Received: from localhost ([127.0.0.1]:41143 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1T10Ex-0004EF-B7; Mon, 13 Aug 2012 21:23:51 +0200 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: Mon, 13 Aug 2012 19:23:51 -0000 X-URL: http://tools.ietf.org/wg/clue/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/clue/trac/ticket/8#comment:3 Message-ID: <083.b37b323beddc695be200300b4748df2c@trac.tools.ietf.org> References: <068.588d2435268c3816b1025ee877475a97@trac.tools.ietf.org> X-Trac-Ticket-ID: 8 In-Reply-To: <068.588d2435268c3816b1025ee877475a97@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.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 grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: allyn@cisco.com, apeppere@gmail.com, bbaldino@cisco.com, mark.duckworth@polycom.com Resent-Message-Id: <20120813192402.D70EB21F8627@ietfa.amsl.com> Resent-Date: Mon, 13 Aug 2012 12:24:02 -0700 (PDT) Resent-From: trac+clue@trac.tools.ietf.org Cc: clue@ietf.org Subject: Re: [clue] #8: How consumer differentiates between multiple capture scenes 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: Mon, 13 Aug 2012 19:24:03 -0000 #8: How consumer differentiates between multiple capture scenes Changes (by mary.ietf.barnes@…): * status: new => closed * resolution: => fixed Comment: Ticket is being closed as the Description attribute for a capture scene is believed to address this. -- --------------------------------+------------------------------------------ Reporter: mary.ietf.barnes@… | Owner: draft-ietf-clue-framework@… Type: task | Status: closed Priority: major | Milestone: milestone1 Component: framework | Version: Severity: Active WG Document | Resolution: fixed Keywords: | --------------------------------+------------------------------------------ Ticket URL: clue From trac+clue@trac.tools.ietf.org Mon Aug 13 12:28: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 3E16A21F84DC for ; Mon, 13 Aug 2012 12:28:05 -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 WVMRAK6NYbUK for ; Mon, 13 Aug 2012 12:28:04 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id AC1AD21F84C2 for ; Mon, 13 Aug 2012 12:28:04 -0700 (PDT) Received: from localhost ([127.0.0.1]:41266 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1T10Iy-0005U6-Bf; Mon, 13 Aug 2012 21:28:00 +0200 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: Mon, 13 Aug 2012 19:28:00 -0000 X-URL: http://tools.ietf.org/wg/clue/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/clue/trac/ticket/9#comment:1 Message-ID: <083.effd7c145b946d899470db353d54c009@trac.tools.ietf.org> References: <068.55b235ae09bcadb5a9adc0e971bc9935@trac.tools.ietf.org> X-Trac-Ticket-ID: 9 In-Reply-To: <068.55b235ae09bcadb5a9adc0e971bc9935@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.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 grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: allyn@cisco.com, apeppere@gmail.com, bbaldino@cisco.com, mark.duckworth@polycom.com Resent-Message-Id: <20120813192804.AC1AD21F84C2@ietfa.amsl.com> Resent-Date: Mon, 13 Aug 2012 12:28:04 -0700 (PDT) Resent-From: trac+clue@trac.tools.ietf.org Cc: clue@ietf.org Subject: Re: [clue] #9: Axis of capture description 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: Mon, 13 Aug 2012 19:28:05 -0000 #9: Axis of capture description Comment (by mary.ietf.barnes@…): Based on discussions at IETF-84, Rob is to post some text to address this ticket on the mailing list. -- --------------------------------+------------------------------------------ Reporter: mary.ietf.barnes@… | Owner: draft-ietf-clue-framework@… Type: enhancement | Status: new Priority: major | Milestone: milestone1 Component: framework | Version: Severity: Active WG Document | Resolution: Keywords: | --------------------------------+------------------------------------------ Ticket URL: clue From trac+clue@trac.tools.ietf.org Mon Aug 13 12:30: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 8635721F862B for ; Mon, 13 Aug 2012 12:30:23 -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 1SqA1lqGkp9E for ; Mon, 13 Aug 2012 12:30:23 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id F250821F862A for ; Mon, 13 Aug 2012 12:30:22 -0700 (PDT) Received: from localhost ([127.0.0.1]:41347 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1T10LC-00061T-Ly; Mon, 13 Aug 2012 21:30:18 +0200 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: Mon, 13 Aug 2012 19:30:18 -0000 X-URL: http://tools.ietf.org/wg/clue/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/clue/trac/ticket/10#comment:2 Message-ID: <083.9c6ae113c733ac78ffdf8c096713b572@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: 127.0.0.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 grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: allyn@cisco.com, apeppere@gmail.com, bbaldino@cisco.com, mark.duckworth@polycom.com Resent-Message-Id: <20120813193022.F250821F862A@ietfa.amsl.com> Resent-Date: Mon, 13 Aug 2012 12:30:22 -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: Mon, 13 Aug 2012 19:30:23 -0000 #10: Does framework provide sufficient info for the receiver? Comment (by mary.ietf.barnes@…): Based on discussions at IETF_84, this ticket will remain open until there are more solution details and then we can revisit this issue. -- --------------------------------+------------------------------------------ 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 trac+clue@trac.tools.ietf.org Mon Aug 13 12:34: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 C8F4121F84FE for ; Mon, 13 Aug 2012 12:34:04 -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, 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 dW0JMFM7k8Ya for ; Mon, 13 Aug 2012 12:34:04 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 19A5821F8600 for ; Mon, 13 Aug 2012 12:34:04 -0700 (PDT) Received: from localhost ([127.0.0.1]:41669 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1T10Ok-0004Qc-5U; Mon, 13 Aug 2012 21:33:58 +0200 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: Mon, 13 Aug 2012 19:33:58 -0000 X-URL: http://tools.ietf.org/wg/clue/ X-Trac-Ticket-URL: http://grenache.tools.ietf.org/wg/clue/trac/ticket/11 Message-ID: <068.5ca029063d5e7080dd9f9169d703adcf@trac.tools.ietf.org> X-Trac-Ticket-ID: 11 X-SA-Exim-Connect-IP: 127.0.0.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 grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: mary.barnes@polycom.com, pkyzivat@alum.mit.edu, Resent-Message-Id: <20120813193404.19A5821F8600@ietfa.amsl.com> Resent-Date: Mon, 13 Aug 2012 12:34:04 -0700 (PDT) Resent-From: trac+clue@trac.tools.ietf.org Cc: clue@ietf.org Subject: [clue] #11: RTP header extension for Capture ID 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: Mon, 13 Aug 2012 19:34:04 -0000 #11: RTP header extension for Capture ID Is an RTP header extension needed to transport a capture ID (per draft- lennox-clue-rtp-usage-04)? -- -----------------------------------+--------------------------- Reporter: mary.ietf.barnes@… | Owner: clue-chairs@… Type: defect | Status: new Priority: major | Milestone: milestone1 Component: charter | Version: 1.0 Severity: Candidate WG Document | Keywords: RTP -----------------------------------+--------------------------- Ticket URL: clue From mary.ietf.barnes@gmail.com Mon Aug 13 12:37: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 421DD21F8629 for ; Mon, 13 Aug 2012 12:37:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.535 X-Spam-Level: X-Spam-Status: No, score=-103.535 tagged_above=-999 required=5 tests=[AWL=0.063, 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 O6SFkjk71USH for ; Mon, 13 Aug 2012 12:37:27 -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 5F7D821F85D8 for ; Mon, 13 Aug 2012 12:37:27 -0700 (PDT) Received: by lahm15 with SMTP id m15so2312490lah.31 for ; Mon, 13 Aug 2012 12:37: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 :content-type; bh=mQbrnCs5I989XBx/Xojp+SPiR25hA7Um+Cmja9whLEA=; b=qKAcCF6RiHn1/EGpA1nsH7E8ORdw2MzhMXe3IqcJjaQLoxbgVzZCzvA0s5mdfikNXq +RvOJVoTLLE+ynd0hQti/lenpBM65Ep3scmm5uyWIqzSfcMzSPMsEDCjZt6W6ynTWJ+e syRKjv/xyfvY5P+GIdqPWvEw9u21JwyttV0rvZGhrNBtvBGm5e4ucTuOm+dn9sRFLIwv Xe2+IkzBzLlLXitGrt+2sf0sQSFpYcNQHIDN61RejYuJki1eXzH48GVRiY1Ix9B5ftxG 82GUIsdvu5BLa9ftoHtI+S0+G+jnpvso6ihP7FUeS2r7I1dJt+tDtryjE0YHInSu55s0 oHIQ== MIME-Version: 1.0 Received: by 10.152.112.234 with SMTP id it10mr12983136lab.36.1344886646302; Mon, 13 Aug 2012 12:37:26 -0700 (PDT) Received: by 10.112.85.196 with HTTP; Mon, 13 Aug 2012 12:37:26 -0700 (PDT) In-Reply-To: <068.5ca029063d5e7080dd9f9169d703adcf@trac.tools.ietf.org> References: <068.5ca029063d5e7080dd9f9169d703adcf@trac.tools.ietf.org> Date: Mon, 13 Aug 2012 14:37:26 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=f46d04083919d0e6c304c72ad254 Subject: [clue] Fwd: #11: RTP header extension for Capture ID 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, 13 Aug 2012 19:37:28 -0000 --f46d04083919d0e6c304c72ad254 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi all, I have updated/closed the issues as discussed at the meeting (and captured in the minutes): http://www.ietf.org/proceedings/84/minutes/minutes-84-clu= e I decided to open a ticket to track this issue since it does require some mailing list discussion and hopefully, this will trigger that. The action items from the meeting that are not related to issues are updates to documents - i.e., new data model document and adding telemedical use case to the WG use case document. Mary. ---------- Forwarded message ---------- From: clue issue tracker Date: Mon, Aug 13, 2012 at 2:33 PM Subject: [clue] #11: RTP header extension for Capture ID To: clue-chairs@tools.ietf.org, mary.ietf.barnes@gmail.com Cc: clue@ietf.org #11: RTP header extension for Capture ID Is an RTP header extension needed to transport a capture ID (per draft- lennox-clue-rtp-usage-04)? -- -----------------------------------+--------------------------- Reporter: mary.ietf.barnes@=85 | Owner: clue-chairs@=85 Type: defect | Status: new Priority: major | Milestone: milestone1 Component: charter | Version: 1.0 Severity: Candidate WG Document | Keywords: RTP -----------------------------------+--------------------------- Ticket URL: clue --f46d04083919d0e6c304c72ad254 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi all,

I have updated/closed the issues as discussed at= the meeting (and captured in the minutes): =A0http://www.ietf.org/proceedings/= 84/minutes/minutes-84-clue

I decided to open a ticket to track this issue since it= does require some mailing list discussion and hopefully, this will trigger= that. =A0

The action items from the meeting that = are not related to issues are updates to documents - i.e., new data model d= ocument and adding telemedical use case to the WG use case document.=A0

Mary.=A0

---------- F= orwarded message ----------
From: clue iss= ue tracker <trac+clue@trac.tools.ietf.org>
Date: Mon, Aug 13, 2012 at 2:33 PM
Subject: [clue] #11: RTP header exten= sion for Capture ID
To: cl= ue-chairs@tools.ietf.org, mary.ietf.barnes@gmail.com
Cc: clue@ietf.org


#11: RTP = header extension for Capture ID

=A0Is an RTP header extension needed to transport a capture ID (per draft-<= br> =A0lennox-clue-rtp-usage-04)?

--
-----------------------------------+---------------------------
=A0Reporter: =A0mary.ietf.barnes@=85 =A0 =A0 | =A0 =A0 =A0Owner: =A0clue-ch= airs@=85
=A0 =A0 =A0Type: =A0defect =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 Status= : =A0new
=A0Priority: =A0major =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0Milestone: = =A0milestone1
Component: =A0charter =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0Version: =A01= .0
=A0Severity: =A0Candidate WG Document =A0| =A0 Keywords: =A0RTP
-----------------------------------+---------------------------

Ticket URL: <http://grenache.tools.ietf.org/wg/clue/trac/ticket= /11>
clue <http:= //tools.ietf.org/wg/clue/>


--f46d04083919d0e6c304c72ad254-- From Christian.Groves@nteczone.com Mon Aug 13 16:12: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 6C6D721F867B for ; Mon, 13 Aug 2012 16:12:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.503 X-Spam-Level: X-Spam-Status: No, score=-2.503 tagged_above=-999 required=5 tests=[AWL=0.096, 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 jsLyKE2iLA8A for ; Mon, 13 Aug 2012 16:12:19 -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 986B421F8602 for ; Mon, 13 Aug 2012 16:12:18 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApYBAC+JKVB20crt/2dsb2JhbAANOIYBsFeGWQEBAQQjDwEFGyURCxgCAgUWCwICCQMCAQIBRRMIAQGsXm6TWYEhiXEkgnGCCoESA6hM Received: from ppp118-209-202-237.lns20.mel6.internode.on.net (HELO [127.0.0.1]) ([118.209.202.237]) by ipmail06.adl2.internode.on.net with ESMTP; 14 Aug 2012 08:42:17 +0930 Message-ID: <502989CD.1010206@nteczone.com> Date: Tue, 14 Aug 2012 09:12:13 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: clue@ietf.org References: <068.588d2435268c3816b1025ee877475a97@trac.tools.ietf.org> <083.b37b323beddc695be200300b4748df2c@trac.tools.ietf.org> In-Reply-To: <083.b37b323beddc695be200300b4748df2c@trac.tools.ietf.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [clue] #8: How consumer differentiates between multiple capture scenes 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, 13 Aug 2012 23:12:19 -0000 Hello Mary, You can close this but I think there is still work to be done on the area of identifying and characterising captures. I'm preparing a draft on this area. Regards, Christian On 14/08/2012 5:23 AM, clue issue tracker wrote: > #8: How consumer differentiates between multiple capture scenes > > Changes (by mary.ietf.barnes@…): > > * status: new => closed > * resolution: => fixed > > > Comment: > > Ticket is being closed as the Description attribute for a capture scene is > believed to address this. > From mary.ietf.barnes@gmail.com Tue Aug 14 06:19: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 EAF9421F86E0 for ; Tue, 14 Aug 2012 06:19:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.702 X-Spam-Level: X-Spam-Status: No, score=-102.702 tagged_above=-999 required=5 tests=[AWL=-0.770, 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 OjntXtMZrBQE for ; Tue, 14 Aug 2012 06:19:34 -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 2CFD721F86DA for ; Tue, 14 Aug 2012 06:19:33 -0700 (PDT) Received: by lahm15 with SMTP id m15so230174lah.31 for ; Tue, 14 Aug 2012 06:19:32 -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=1iC6zgwr5mewEhHKB0dDt0WWPaSKgSzTkytL3l4upNc=; b=jtCXk51kN8s385SM1T5NPHdh7BwABx4YbparHTQX98ONwzRDamKNOGSYY6xDv26YoN 4DQ3pzFLMfD3RVUrGjbv8iE62O69n9h+6QB7NloKM5V9V+JyENJ6Ah56QqHxHHYatMe0 T5eHnKg8l1nTR9wNGscRyxkLTgrSowlx5lHL0r6XZ7XliHOozdwmk0+0TIiHNf+GgLvo Fz+thSRhKrqKJedLH51oQsRLtTt1pXkIBfG+RbvNOtIk+fkjFc2GhGvKpTCdwaJwMEIu HdxImPsFkjeWR4RAT3OzFKoAiMpz91oRp16+iA6YN2JoD9EykxoFRzlVdEuKK/ACGVn8 VT8w== MIME-Version: 1.0 Received: by 10.152.104.77 with SMTP id gc13mr15676155lab.31.1344950372891; Tue, 14 Aug 2012 06:19:32 -0700 (PDT) Received: by 10.112.85.196 with HTTP; Tue, 14 Aug 2012 06:19:32 -0700 (PDT) In-Reply-To: <502989CD.1010206@nteczone.com> References: <068.588d2435268c3816b1025ee877475a97@trac.tools.ietf.org> <083.b37b323beddc695be200300b4748df2c@trac.tools.ietf.org> <502989CD.1010206@nteczone.com> Date: Tue, 14 Aug 2012 08:19:32 -0500 Message-ID: From: Mary Barnes To: Christian Groves Content-Type: multipart/alternative; boundary=f46d04083adb377c4e04c739a94e Cc: clue@ietf.org Subject: Re: [clue] #8: How consumer differentiates between multiple capture scenes 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, 14 Aug 2012 13:19:35 -0000 --f46d04083adb377c4e04c739a94e Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable That's fine - the discussion at the meeting (and the point in Mark's charts) was that if there is a solid proposal, we could reconsider. However, we really do need to move on from the framework into solution space. Mary. On Mon, Aug 13, 2012 at 6:12 PM, Christian Groves < Christian.Groves@nteczone.com> wrote: > Hello Mary, > > You can close this but I think there is still work to be done on the area > of identifying and characterising captures. I'm preparing a draft on this > area. > > Regards, Christian > > > On 14/08/2012 5:23 AM, clue issue tracker wrote: > >> #8: How consumer differentiates between multiple capture scenes >> >> Changes (by mary.ietf.barnes@=85): >> >> * status: new =3D> closed >> * resolution: =3D> fixed >> >> >> Comment: >> >> Ticket is being closed as the Description attribute for a capture scen= e >> is >> believed to address this. >> >> > ______________________________**_________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/**listinfo/clue > --f46d04083adb377c4e04c739a94e Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable That's fine - the discussion at the meeting (and the point in Mark'= s charts) was that if there is a solid proposal, we could reconsider. =A0 H= owever, we really do need to move on from the framework into solution space= . =A0

Mary.=A0

On Mon, Aug 13, 2= 012 at 6:12 PM, Christian Groves <Christian.Groves@nteczone.co= m> wrote:
Hello Mary,

You can close this but I think there is still work to be done on the area o= f identifying and characterising captures. I'm preparing a draft on thi= s area.

Regards, Christian


On 14/08/2012 5:23 AM, clue issue tracker wrote:
#8: How consumer differentiates between multiple capture scenes

Changes (by mary.ietf.barnes@=85):

=A0 * status: =A0new =3D> closed
=A0 * resolution: =A0 =3D> fixed


Comment:

=A0 Ticket is being closed as the Description attribute for a capture scene= is
=A0 believed to address this.


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

--f46d04083adb377c4e04c739a94e-- From mary.ietf.barnes@gmail.com Tue Aug 14 06:54: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 51C2021F8661 for ; Tue, 14 Aug 2012 06:54:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.529 X-Spam-Level: X-Spam-Status: No, score=-103.529 tagged_above=-999 required=5 tests=[AWL=0.069, 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 u+-XQwIvD7M3 for ; Tue, 14 Aug 2012 06:54:34 -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 8A3E021F861E for ; Tue, 14 Aug 2012 06:54:34 -0700 (PDT) Received: by lbbgg6 with SMTP id gg6so291107lbb.31 for ; Tue, 14 Aug 2012 06:54: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:content-type; bh=G+DsE9u5rBzjF0/xZ8hfcphwdse8lNZccT9Bt+I3Bag=; b=NLCq79lNtAFIYLxcW7XytmUuKA+FtZWhydMYbmF2/DkjYxDfQrziN9A/kgtEL2+Ej9 UpIt9thRorsKw/fenTkekTYoJj7fvaiJZclVkZcx0FVt/7xFPgKSTLMhwBBnc1RogRnz +xdtj4eEcVKlDst1ETOpHgo2LejZ0uRaJZzmOodWHsTxfggv+2Jz0c4RNdogS7/gHC+u ynH9U2hAxMTConFhR4gc7Sbv+6WOy+e5FyvBa3bF+Xfq7GBUte7+ALWbfI5QIgZVkW12 Wz0T3o2eO2Tlx7Zveek33TSQlK8Iq+kROYKMDZkfVb1x9CUd7w5yxmC4bRRkWhX6bWUc peDA== MIME-Version: 1.0 Received: by 10.112.82.6 with SMTP id e6mr1750655lby.93.1344952473428; Tue, 14 Aug 2012 06:54:33 -0700 (PDT) Received: by 10.112.85.196 with HTTP; Tue, 14 Aug 2012 06:54:33 -0700 (PDT) Date: Tue, 14 Aug 2012 08:54:33 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=f46d0401f9296b253f04c73a267d Subject: [clue] Topic for today's call 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, 14 Aug 2012 13:54:35 -0000 --f46d0401f9296b253f04c73a267d Content-Type: text/plain; charset=ISO-8859-1 The one topic that I think we might benefit from discussing is the new issue #11: http://tools.ietf.org/wg/clue/trac/ticket/11 Mary. --f46d0401f9296b253f04c73a267d Content-Type: text/html; charset=ISO-8859-1 The one topic that I think we might benefit from discussing is the new issue #11:

Mary.
--f46d0401f9296b253f04c73a267d-- From ron.even.tlv@gmail.com Tue Aug 14 07:56: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 6432421F865E for ; Tue, 14 Aug 2012 07:56:37 -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 xki3frF+W9qP for ; Tue, 14 Aug 2012 07:56:36 -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 67F2821F851B for ; Tue, 14 Aug 2012 07:56:29 -0700 (PDT) Received: by wibhr14 with SMTP id hr14so383892wib.13 for ; Tue, 14 Aug 2012 07:56:28 -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=zCNefVkQ/sQl85em183lLBbRSgI78SbzqLvscUEof58=; b=w5RcAgcCgANMjR7R8aJSPNI1jkl76NXuepxZNdcs86XY9kudQGfI0cUWLk2J8yy2sb YQkliVWOoL6eq8TLIK4BHAlv8QkHygAQGu1JfqKNd6CjDC8QYREUFutYXvho/cou/qmL kz6WFP4Rz0ZJr4CGwkp6uRbQw2k89uoDa3VXKKvyA304MKb5fQ4KBCE6Ih0DStkbw1nM yEK609cLyDUsmmJ5KuJn3iSE6vpePflEgpvC/ACFAMoRvwrMq5zHGDIbg1CXmGbHZ+UA ODnpjQTq+UJJBMPoKwKKrxeTJ7SXq1172UPSGqXBt6FDYtdNcHmb8j6+cQk25yvKoYfm 0/VA== Received: by 10.180.98.138 with SMTP id ei10mr28568875wib.1.1344956188599; Tue, 14 Aug 2012 07:56:28 -0700 (PDT) Received: from RoniE ([109.65.229.195]) by mx.google.com with ESMTPS id t7sm33272743wix.6.2012.08.14.07.56.26 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 14 Aug 2012 07:56:27 -0700 (PDT) From: "Roni Even" To: References: <068.5ca029063d5e7080dd9f9169d703adcf@trac.tools.ietf.org> In-Reply-To: <068.5ca029063d5e7080dd9f9169d703adcf@trac.tools.ietf.org> Date: Tue, 14 Aug 2012 17:55:16 +0200 Message-ID: <002601cd7a35$3460b1e0$9d2215a0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFM/VlsLWUUBwuvWjT5seMrvYeAmZhaaTig Content-Language: en-us Subject: Re: [clue] #11: RTP header extension for Capture ID 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, 14 Aug 2012 14:56:37 -0000 Hi, I am not sure that this is the right description. Both presentation had = the header extension as a solution. The comment by Colin at the meeting was that header extensions are = designed so that they may be ignored without affecting the = interoperability (see section 4.1 of RFC5285). The major issue raised by = Colin is that intermediaries may strip the header extension and the = interoperability should not be broken. My understanding is that even if = it is negotiated in SDP that does not guarantee that the header = extension will not be stripped. So the question is if it is a reasonable solution according to RFC3550 = and RFC5285 and not if it is needed. Roni -----Original Message----- From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of = clue issue tracker Sent: 13 August, 2012 9:34 PM To: clue-chairs@tools.ietf.org; mary.ietf.barnes@gmail.com Cc: clue@ietf.org Subject: [clue] #11: RTP header extension for Capture ID #11: RTP header extension for Capture ID Is an RTP header extension needed to transport a capture ID (per draft- = lennox-clue-rtp-usage-04)? --=20 -----------------------------------+--------------------------- Reporter: mary.ietf.barnes@=E2=80=A6 | Owner: = clue-chairs@=E2=80=A6 Type: defect | Status: new Priority: major | Milestone: milestone1 Component: charter | Version: 1.0 Severity: Candidate WG Document | Keywords: RTP -----------------------------------+--------------------------- Ticket URL: clue _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue From mary.ietf.barnes@gmail.com Tue Aug 14 08:09: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 9660421F86F8 for ; Tue, 14 Aug 2012 08:09:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.529 X-Spam-Level: X-Spam-Status: No, score=-103.529 tagged_above=-999 required=5 tests=[AWL=0.069, 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 V014ln1PqVK9 for ; Tue, 14 Aug 2012 08:09:09 -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 3B76321F8630 for ; Tue, 14 Aug 2012 08:09:09 -0700 (PDT) Received: by lbbgg6 with SMTP id gg6so338283lbb.31 for ; Tue, 14 Aug 2012 08:09: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=slRTTWlbv9Jgh00+6BkU8IZ/CVVpi827I311+rQnDMo=; b=ZiH98WDOOl+jCbcB2FVcESQoJwTsoSmEuqpZgVeXav6cqhfDb6xDCPLLFRQbjhgkv7 pNfOnfTbMNeAzCuTRC9EeEgpl3OkccOOiNuDETG98uriFEBK2zaiZkSpBRdR2g73Lo1q /pheJcqPJFMp+Y5B0oO/r9GZzSgHG8GKmGwBXokQaD/WEqczOlx825y6cM13vadxDnLD 0kpKUS8l6i+1mdCNERVT9rSKXB8dlz79IjAi7XQQr7A/5NyDMTxV+aOfzuCU9DHH0bJP EM5OfHPBjXvm04ynS8PX1I09wa662Xma8ReWSky3jvrytAmiMN7NXSiKpTHTMYw4jHUo VQpA== MIME-Version: 1.0 Received: by 10.152.112.234 with SMTP id it10mr16002726lab.36.1344956946953; Tue, 14 Aug 2012 08:09:06 -0700 (PDT) Received: by 10.112.85.196 with HTTP; Tue, 14 Aug 2012 08:09:06 -0700 (PDT) In-Reply-To: <002601cd7a35$3460b1e0$9d2215a0$@gmail.com> References: <068.5ca029063d5e7080dd9f9169d703adcf@trac.tools.ietf.org> <002601cd7a35$3460b1e0$9d2215a0$@gmail.com> Date: Tue, 14 Aug 2012 10:09:06 -0500 Message-ID: From: Mary Barnes To: Roni Even Content-Type: multipart/alternative; boundary=f46d040839190fb68704c73b3111 Cc: clue@ietf.org Subject: Re: [clue] #11: RTP header extension for Capture ID 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, 14 Aug 2012 15:09:10 -0000 --f46d040839190fb68704c73b3111 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable You are correct. I noted that on the call today that question/issue was not properly stated. I'll send the notes from the call shortly. Mary. On Tue, Aug 14, 2012 at 10:55 AM, Roni Even wrote: > Hi, > I am not sure that this is the right description. Both presentation had > the header extension as a solution. > The comment by Colin at the meeting was that header extensions are > designed so that they may be ignored without affecting the interoperabili= ty > (see section 4.1 of RFC5285). The major issue raised by Colin is that > intermediaries may strip the header extension and the interoperability > should not be broken. My understanding is that even if it is negotiated i= n > SDP that does not guarantee that the header extension will not be strippe= d. > So the question is if it is a reasonable solution according to RFC3550 an= d > RFC5285 and not if it is needed. > Roni > > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > clue issue tracker > Sent: 13 August, 2012 9:34 PM > To: clue-chairs@tools.ietf.org; mary.ietf.barnes@gmail.com > Cc: clue@ietf.org > Subject: [clue] #11: RTP header extension for Capture ID > > #11: RTP header extension for Capture ID > > Is an RTP header extension needed to transport a capture ID (per draft- > lennox-clue-rtp-usage-04)? > > -- > -----------------------------------+--------------------------- > Reporter: mary.ietf.barnes@=85 | Owner: clue-chairs@=85 > Type: defect | Status: new > Priority: major | Milestone: milestone1 > Component: charter | Version: 1.0 > Severity: Candidate WG Document | Keywords: RTP > -----------------------------------+--------------------------- > > Ticket URL: > 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 > --f46d040839190fb68704c73b3111 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable You are correct. =A0I noted that on the call today that question/issue was = not properly stated. =A0I'll send the notes from the call shortly.
=
Mary.

On T= ue, Aug 14, 2012 at 10:55 AM, Roni Even <ron.even.tlv@gmail.com&g= t; wrote:
Hi,
I am not sure that this is the right description. Both presentation had the= header extension as a solution.
The comment by Colin at the meeting was that header extensions are designed= so that they may be ignored without affecting the interoperability (see se= ction 4.1 of RFC5285). The major issue raised by Colin is that intermediari= es may strip the header extension and the interoperability should not be br= oken. My understanding is that even if it is negotiated in SDP that does no= t guarantee that the header extension will not be stripped.
So the question is if it is a reasonable solution according to RFC3550 and = RFC5285 and not if it is needed.
Roni

-----Original Message-----
From: clue-bounces@ietf.org [m= ailto:clue-bounces@ietf.org] O= n Behalf Of clue issue tracker
Sent: 13 August, 2012 9:34 PM
To: clue-chairs@tools.ietf.or= g; mary.ietf.barnes@gmail= .com
Cc: clue@ietf.org
Subject: [clue] #11: RTP header extension for Capture ID

#11: RTP header extension for Capture ID

=A0Is an RTP header extension needed to transport a capture ID (per draft- = =A0lennox-clue-rtp-usage-04)?

--
-----------------------------------+---------------------------
=A0Reporter: =A0mary.ietf.barnes@=85 =A0 =A0 | =A0 =A0 =A0Owner: =A0clue-ch= airs@=85
=A0 =A0 =A0Type: =A0defect =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 Status= : =A0new
=A0Priority: =A0major =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0Milestone: = =A0milestone1
Component: =A0charter =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0Version: =A01= .0
=A0Severity: =A0Candidate WG Document =A0| =A0 Keywords: =A0RTP
-----------------------------------+---------------------------

Ticket URL: <http://grenache.tools.ietf.org/wg/clue/trac/ticket= /11>
clue <http:= //tools.ietf.org/wg/clue/>

_______________________________________________
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

--f46d040839190fb68704c73b3111-- From christer.holmberg@ericsson.com Tue Aug 14 12:39: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 6616121F87A0 for ; Tue, 14 Aug 2012 12:39:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.144 X-Spam-Level: X-Spam-Status: No, score=-6.144 tagged_above=-999 required=5 tests=[AWL=0.105, 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 3cRBO3CTaLOl for ; Tue, 14 Aug 2012 12:39:36 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 5917E21F879F for ; Tue, 14 Aug 2012 12:39:36 -0700 (PDT) X-AuditID: c1b4fb25-b7f236d000005cde-dd-502aa977e540 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 82.B3.23774.779AA205; Tue, 14 Aug 2012 21:39:35 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.21]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Tue, 14 Aug 2012 21:39:35 +0200 From: Christer Holmberg To: Mary Barnes , CLUE Date: Tue, 14 Aug 2012 21:38:15 +0200 Thread-Topic: [clue] Fwd: #11: RTP header extension for Capture ID Thread-Index: Ac15ixShn6yvZyNiRBeZAkQX/1t3aQAyUSsJ Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585340868365E@ESESSCMS0356.eemea.ericsson.se> References: <068.5ca029063d5e7080dd9f9169d703adcf@trac.tools.ietf.org>, 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="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrDLMWRmVeSWpSXmKPExsUyM+JvrW75Sq0Ag13/FCz2n7rMbPF5/35m ByaPnbPusnssWfKTKYApissmJTUnsyy1SN8ugStj1qc+poIP/BVdc76yNTA+5+li5OSQEDCR 2Pt7ASuELSZx4d56ti5GLg4hgVOMEku2HWaGcBYwSrx7t5K9i5GDg03AQqL7nzZIg4iAk8SF l+9ZQGwWAVWJne+vg9nCQPFjB6ezQ9Q4S6zaO4cRwjaS6NzymAnE5hUIl/hx8QYbiC0k0M0o cXRzBYjNKRAoceXgOrCDGIEO+n5qDVg9s4C4xK0n85kgDhWQWLLnPDOELSrx8vE/qHpRiTvt 6xkh6g0k3p+bzwxha0ssW/iaGWKvoMTJmU9YJjCKzkIydhaSlllIWmYhaVnAyLKKUTg3MTMn vdxIL7UoM7m4OD9Przh1EyMwRg5u+a26g/HOOZFDjNIcLErivNZb9/gLCaQnlqRmp6YWpBbF F5XmpBYfYmTi4JRqYEyfvDXZv+LEpAgVrlfz67yd9zSYsi/8ZuEku02gpb1q6oSJVRfuvlS9 Xc10fY5pmmjlCo8z6sdlJjz+NufE6Z+6bqYGgWclrhoKTfv9Ov9Ew+KF68rOHY8K73p4fpdY xxSPoAOn+10mTvrSdPV5Du91vb6+u029gW6lC344xK99fvvc/Iz0pmlKLMUZiYZazEXFiQCi 6ySTXwIAAA== Subject: Re: [clue] Fwd: #11: RTP header extension for Capture ID 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, 14 Aug 2012 19:39:37 -0000 Hi, A silly question: Is there a reason why we can't use the SSRC? Or, can multiple captures shar= e the same SSRC? Regards, Christer ________________________________ From: clue-bounces@ietf.org [clue-bounces@ietf.org] On Behalf Of Mary Barne= s [mary.ietf.barnes@gmail.com] Sent: Monday, August 13, 2012 10:37 PM To: CLUE Subject: [clue] Fwd: #11: RTP header extension for Capture ID Hi all, I have updated/closed the issues as discussed at the meeting (and captured = in the minutes): http://www.ietf.org/proceedings/84/minutes/minutes-84-clu= e I decided to open a ticket to track this issue since it does require some m= ailing list discussion and hopefully, this will trigger that. The action items from the meeting that are not related to issues are update= s to documents - i.e., new data model document and adding telemedical use c= ase to the WG use case document. Mary. ---------- Forwarded message ---------- From: clue issue tracker > Date: Mon, Aug 13, 2012 at 2:33 PM Subject: [clue] #11: RTP header extension for Capture ID To: clue-chairs@tools.ietf.org, mary.iet= f.barnes@gmail.com Cc: clue@ietf.org #11: RTP header extension for Capture ID Is an RTP header extension needed to transport a capture ID (per draft- lennox-clue-rtp-usage-04)? -- -----------------------------------+--------------------------- Reporter: mary.ietf.barnes@=85 | Owner: clue-chairs@=85 Type: defect | Status: new Priority: major | Milestone: milestone1 Component: charter | Version: 1.0 Severity: Candidate WG Document | Keywords: RTP -----------------------------------+--------------------------- Ticket URL: clue From mary.ietf.barnes@gmail.com Tue Aug 14 12:53: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 AA90521E8096 for ; Tue, 14 Aug 2012 12:53:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.53 X-Spam-Level: X-Spam-Status: No, score=-103.53 tagged_above=-999 required=5 tests=[AWL=0.068, 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 IpjGS4PAiC1b for ; Tue, 14 Aug 2012 12:53:49 -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 BE95521E809B for ; Tue, 14 Aug 2012 12:53:48 -0700 (PDT) Received: by lahm15 with SMTP id m15so454976lah.31 for ; Tue, 14 Aug 2012 12:53: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:content-type; bh=9HRHEDTG+sVGgheLrr9bp0Wak0qnXA98yPolTJ7hEhY=; b=EB3dgu0KlTbZk8sdPo0wrfsdkif78pnjwFtF/JDJYMpo2t+k2fieILFHKylqy5C6eK f66BgI4djY5fLIktvAWDDx/QDcWfxlg0OBtIYP5DNjZs9kezT3pUsMuasmYFIiMKuiC9 50W6DtxPIYZyN5nde9lmbrgyPdnOveiLhHMjZUIgFl2vnitUJyAu84iQXjEtWN6evRDZ E2RMWbDKQHzu0cAOm0bq0xAJbobWiW6ST2B1y+o8equDfsEd7s4fxLrZy8TIu/phVj+J 84UyfLcqFhnYwtrwJ13kL4W4yQY8TsLm35WHmpFZmfeC4IviHjNNP6lM5OpxgwU6zecX UxLg== MIME-Version: 1.0 Received: by 10.152.112.234 with SMTP id it10mr16788587lab.36.1344974027731; Tue, 14 Aug 2012 12:53:47 -0700 (PDT) Received: by 10.112.85.196 with HTTP; Tue, 14 Aug 2012 12:53:47 -0700 (PDT) Date: Tue, 14 Aug 2012 14:53:47 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=f46d0408391927b2a604c73f2b7e Subject: [clue] Notes from today's call (Aug 14) 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, 14 Aug 2012 19:53:49 -0000 --f46d0408391927b2a604c73f2b7e Content-Type: text/plain; charset=ISO-8859-1 Hi all, Here is a summary based on notes I took during today's call. Questions, comments and/or clarifications are welcome. Thanks, Mary. CLUE WG Design team call (August 14, 2012) Attendees: Mary Barnes, John Leslie, Jonathan Lennox, Rob Hansen, Espen Berger The description of the issue is not quite accurate as both RTP drafts have a header extension. There are actual multiple issues around this that need consideration: 1) Do we both the static declaration of capture encoding SSRCs and the RTP header extension method of sharing capture IDs (or just the RTP header)? 2) Where to signal the SSRCs? 3) Whether the capture ID is assigned by the consumer or advertised by the provider? 4) We need a solution that works for non-clue users and we need to ensure that things work in the case of an RTP mixer that might remove the header. We got into discussion of what documents we need for a solution. Jonathan noted that the solutions proposed in the rtp-mapping document are designed to satisfy all the requirements in the rtp-usage draft. Mary raised the concern that additional updates to both docs could cause some divergence (right now the rtp-mapping document references requirements in rtp-usage document). On Tue, Aug 14, 2012 at 8:54 AM, Mary Barnes wrote: > The one topic that I think we might benefit from discussing is the new > issue #11: > http://tools.ietf.org/wg/clue/trac/ticket/11 > > Mary. > --f46d0408391927b2a604c73f2b7e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all,

Here is a summary based on notes I took during t= oday's call. =A0Questions, comments and/or clarifications are welcome.<= /div>

Thanks,
Mary.

CLUE WG Design team call (August 14, 2012)

Attende= es: =A0Mary Barnes, John Leslie, Jonathan Lennox, Rob Hansen, Espen Berger<= /div>

The description of the issue is not quite accurate= as both RTP drafts have a header extension. =A0There are actual multiple i= ssues around this that need consideration:

1) Do we both the static declaration of capture=A0encod= ing SSRCs and the RTP header extension method of sharing capture IDs (or ju= st the RTP header)?
2) Where to signal the SSRCs?
3) Wh= ether =A0the capture ID is assigned by the consumer or advertised by the pr= ovider?=A0
4) We need a solution that works for non-clue users and we need to ens= ure that things work in the case of an RTP mixer that might remove the head= er.=A0

We got into discussion of what documents we= need for a solution. =A0Jonathan noted that the solutions proposed in the = rtp-mapping document are designed to satisfy all the requirements in the rt= p-usage draft. =A0=A0Mary raised the conce= rn that additional updates to both docs could cause some divergence (right = now the rtp-mapping document references requirements in rtp-usage document)= . =A0 =A0=A0=A0


On Tue, Aug 14, 2012 at = 8:54 AM, Mary Barnes <mary.ietf.barnes@gmail.com> w= rote:
The one topic that I think we might benefit = from discussing is the new issue #11:

Mary.

--f46d0408391927b2a604c73f2b7e-- From ron.even.tlv@gmail.com Tue Aug 14 13:18: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 9A30F21E8087 for ; Tue, 14 Aug 2012 13:18:59 -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.000, 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 KAwbhPYAJfNA for ; Tue, 14 Aug 2012 13:18:58 -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 9F7FE21E804C for ; Tue, 14 Aug 2012 13:18:58 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so516181wgb.13 for ; Tue, 14 Aug 2012 13:18:57 -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=+rbW9adYyIdC9kqReDckrqvGoOYMm4wkyhFfQ63Di5o=; b=BbAwYQFCVRBxfYdJRdSxyMa3YXpkx1myfzFlJpzRzBTi/4WJAsqnGXU4b4o1v63vfE SsEt8jb/GW57K4FU5rHD9Cm3Gg0ZKMYueeeoGdo66oUZURlLVYmoiV87qy/feVHsc2JN 6fYP0xrx0RcP6y6BUZtJ4FVPIqKuckwhBWOVt6v+ggmbIn3cCbXJBRL9p0mRP3WTH1Jx QbcIcs820ejDbHrxpFhiKjJI57g8MWR9HQx2BglpcorE1vzmEMe/RZMMG3Wm1sC+aglf X4rXJd9reYFwjVChRHdCvrUEQIT+IyBU0p4Ad8mJBYY5Ez0XZmEKdK9eIqQsen7my3EC H5Jw== Received: by 10.216.241.198 with SMTP id g48mr5432067wer.192.1344975537776; Tue, 14 Aug 2012 13:18:57 -0700 (PDT) Received: from RoniE ([109.65.229.195]) by mx.google.com with ESMTPS id l5sm35363253wix.5.2012.08.14.13.18.53 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 14 Aug 2012 13:18:56 -0700 (PDT) From: "Roni Even" To: "'Christer Holmberg'" , "'Mary Barnes'" , "'CLUE'" References: <068.5ca029063d5e7080dd9f9169d703adcf@trac.tools.ietf.org>, <7F2072F1E0DE894DA4B517B93C6A0585340868365E@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585340868365E@ESESSCMS0356.eemea.ericsson.se> Date: Tue, 14 Aug 2012 23:17:42 +0200 Message-ID: <005201cd7a62$40e62260$c2b26720$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFM/VlsLWUUBwuvWjT5seMrvYeAmQJvL0GbAjiJEHOYNYrycA== Content-Language: en-us Subject: Re: [clue] Fwd: #11: RTP header extension for Capture ID 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, 14 Aug 2012 20:18:59 -0000 Hi Christer, This works for static SSRCs when the mixer uses its own SSRC. The problem is in the switching case when using the source SSRC. An example is when a three camera system has two captures to send to a two monitor system. The three camera system may send first the left and center camera but when switching to center and right camera the center camera will switch from right capture to left capture. This was discussed in my presentation in CLUE about mapping RTP streams. Roni -----Original Message----- From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Christer Holmberg Sent: 14 August, 2012 9:38 PM To: Mary Barnes; CLUE Subject: Re: [clue] Fwd: #11: RTP header extension for Capture ID Hi, A silly question: Is there a reason why we can't use the SSRC? Or, can multiple captures share the same SSRC? Regards, Christer ________________________________ From: clue-bounces@ietf.org [clue-bounces@ietf.org] On Behalf Of Mary Barnes [mary.ietf.barnes@gmail.com] Sent: Monday, August 13, 2012 10:37 PM To: CLUE Subject: [clue] Fwd: #11: RTP header extension for Capture ID Hi all, I have updated/closed the issues as discussed at the meeting (and captured in the minutes): http://www.ietf.org/proceedings/84/minutes/minutes-84-clue I decided to open a ticket to track this issue since it does require some mailing list discussion and hopefully, this will trigger that. The action items from the meeting that are not related to issues are updates to documents - i.e., new data model document and adding telemedical use case to the WG use case document. Mary. ---------- Forwarded message ---------- From: clue issue tracker > Date: Mon, Aug 13, 2012 at 2:33 PM Subject: [clue] #11: RTP header extension for Capture ID To: clue-chairs@tools.ietf.org, mary.ietf.barnes@gmail.com Cc: clue@ietf.org #11: RTP header extension for Capture ID Is an RTP header extension needed to transport a capture ID (per draft- lennox-clue-rtp-usage-04)? -- -----------------------------------+--------------------------- Reporter: mary.ietf.barnes@. | Owner: clue-chairs@. Type: defect | Status: new Priority: major | Milestone: milestone1 Component: charter | Version: 1.0 Severity: Candidate WG Document | Keywords: RTP -----------------------------------+--------------------------- Ticket URL: clue _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue From pkyzivat@alum.mit.edu Tue Aug 14 13:40: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 47ACE21E808E for ; Tue, 14 Aug 2012 13:40:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.223 X-Spam-Level: X-Spam-Status: No, score=-1.223 tagged_above=-999 required=5 tests=[AWL=-0.786, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.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 cr0Pgsfy1mB3 for ; Tue, 14 Aug 2012 13:40:23 -0700 (PDT) Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:24]) by ietfa.amsl.com (Postfix) with ESMTP id E02F921E8085 for ; Tue, 14 Aug 2012 13:40:18 -0700 (PDT) Received: from omta10.westchester.pa.mail.comcast.net ([76.96.62.28]) by qmta02.westchester.pa.mail.comcast.net with comcast id mi771j0010cZkys51kgMsx; Tue, 14 Aug 2012 20:40:21 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta10.westchester.pa.mail.comcast.net with comcast id mkgL1j00J3ZTu2S3WkgL58; Tue, 14 Aug 2012 20:40:20 +0000 Message-ID: <502AB7B1.4070506@alum.mit.edu> Date: Tue, 14 Aug 2012 16:40: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: <068.5ca029063d5e7080dd9f9169d703adcf@trac.tools.ietf.org>, <7F2072F1E0DE894DA4B517B93C6A0585340868365E@ESESSCMS0356.eemea.ericsson.se> <005201cd7a62$40e62260$c2b26720$@gmail.com> In-Reply-To: <005201cd7a62$40e62260$c2b26720$@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] Fwd: #11: RTP header extension for Capture ID 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, 14 Aug 2012 20:40:24 -0000 On 8/14/12 5:17 PM, Roni Even wrote: > Hi Christer, > This works for static SSRCs when the mixer uses its own SSRC. The problem is > in the switching case when using the source SSRC. An example is when a three > camera system has two captures to send to a two monitor system. The three > camera system may send first the left and center camera but when switching > to center and right camera the center camera will switch from right capture > to left capture. > This was discussed in my presentation in CLUE about mapping RTP streams. AFAIK it *could* work using SSRC. But then there are different constraints on how RTP is used. For instance, for the switched case it would then be necessary to assign an ssrc for the switched capture, and indicate the source via csrc. It also then means that if a source is moved from one switched capture to a different one, the recipient won't know that it is the *same* RTP stream. And that affects the number of iframes transmitted, etc. tradeoffs! Thanks, Paul > Roni > > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Christer Holmberg > Sent: 14 August, 2012 9:38 PM > To: Mary Barnes; CLUE > Subject: Re: [clue] Fwd: #11: RTP header extension for Capture ID > > Hi, > > A silly question: > > Is there a reason why we can't use the SSRC? Or, can multiple captures share > the same SSRC? > > Regards, > > Christer > > ________________________________ > From: clue-bounces@ietf.org [clue-bounces@ietf.org] On Behalf Of Mary Barnes > [mary.ietf.barnes@gmail.com] > Sent: Monday, August 13, 2012 10:37 PM > To: CLUE > Subject: [clue] Fwd: #11: RTP header extension for Capture ID > > Hi all, > > I have updated/closed the issues as discussed at the meeting (and captured > in the minutes): http://www.ietf.org/proceedings/84/minutes/minutes-84-clue > > I decided to open a ticket to track this issue since it does require some > mailing list discussion and hopefully, this will trigger that. > > The action items from the meeting that are not related to issues are updates > to documents - i.e., new data model document and adding telemedical use case > to the WG use case document. > > Mary. > > ---------- Forwarded message ---------- > From: clue issue tracker > > > Date: Mon, Aug 13, 2012 at 2:33 PM > Subject: [clue] #11: RTP header extension for Capture ID > To: clue-chairs@tools.ietf.org, > mary.ietf.barnes@gmail.com > Cc: clue@ietf.org > > > #11: RTP header extension for Capture ID > > Is an RTP header extension needed to transport a capture ID (per draft- > lennox-clue-rtp-usage-04)? > > -- > -----------------------------------+--------------------------- > Reporter: mary.ietf.barnes@. | Owner: clue-chairs@. > Type: defect | Status: new > Priority: major | Milestone: milestone1 > Component: charter | Version: 1.0 > Severity: Candidate WG Document | Keywords: RTP > -----------------------------------+--------------------------- > > Ticket URL: > 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 Tue Aug 14 14:35: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 8B61921E80B4 for ; Tue, 14 Aug 2012 14:35:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.601 X-Spam-Level: X-Spam-Status: No, score=-102.601 tagged_above=-999 required=5 tests=[AWL=-0.862, BAYES_20=-0.74, 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 DJQH0w8f1z-I for ; Tue, 14 Aug 2012 14:35:06 -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 8BD5721E8050 for ; Tue, 14 Aug 2012 14:35:05 -0700 (PDT) Received: by lbbgg6 with SMTP id gg6so540382lbb.31 for ; Tue, 14 Aug 2012 14:35: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=eE3GTudJUmsA57f7PMe0EcGk/8cuSooWuwXxuu2uC/Q=; b=CemkyDHdV5zEZrYbzDmIzYiOJRfqQCrigZLIwi8WCeV76qxNnQ+drvj49QS++0ExVl Z3X/jE08KdDnhYOPntPUqeD2Yd1pycxUJogc/TIA5ISHULA5ZezHXPSjqwNo16sy6HVI W6KLzUjngPapHmUxf8Yhm+vzGd1ZxCsoPuCJRSpmdkhrx6uJHY/rZVxVnVnKLqVJXvVB IC2//1yqHHfEl8B+V7arqatfjKVSQLia52w3XNh31BpTvUVtk3fXyRyomO8JulMNaLZY 0VeMscNsIg0cqdE802GYFkl+dEN938JwhxOanj6qfTziac7wD7uY/3OFooRK8bC1jSw2 zDJw== MIME-Version: 1.0 Received: by 10.152.112.234 with SMTP id it10mr17042715lab.36.1344980104511; Tue, 14 Aug 2012 14:35:04 -0700 (PDT) Received: by 10.112.85.196 with HTTP; Tue, 14 Aug 2012 14:35:04 -0700 (PDT) Date: Tue, 14 Aug 2012 16:35:04 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=f46d040839195bfef904c7409530 Subject: [clue] CLUE WG Interim meeting location 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, 14 Aug 2012 21:35:06 -0000 --f46d040839195bfef904c7409530 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cisco has agreed (thanks to David Benham!) to host our interim meeting September 19-20. We will post a preliminary agenda within the next week. The deadline for documents will be in about 4 weeks time (one week before the meeting). The exact dates will be posted when we publish the agenda. Location: **** Cisco Building 30 =96 Globalization Conf Room**** 707 East Tasman Dr (near corner of Alder)**** Milpitas, CA 95035**** ** ** **These two hotels are within walking distance, however, there are other options in the area. **** Crowne Plaza (408) 321-9500**** 777 Bellew Drive**** Milpitas, CA 95035**** ** ** Hampton Inn Milpitas (408) 428-9090**** 215 Barber Court**** Milpitas, CA 95035**** ** ** --f46d040839195bfef904c7409530 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Cisco has agreed (thanks to David Benham!) to host our interim meeting= September 19-20. =A0 We will post a preliminary agenda within the next wee= k. =A0The deadline for documents will be in about 4 weeks time (one week be= fore the meeting). =A0The exact dates will be posted when we publish the ag= enda. =A0=A0

Locati= on:

Cisco = Building 30 =96 Globalization Conf Room

707 Ea= st Tasman Dr (near corner of Alder)

Milpit= as, CA 95035

=A0

These two hotels are within walking distance, however, there are other opt= ions in the area.=A0

=A0

Crowne= Plaza=A0 (408) 321-9500

777 Be= llew Drive

Milpit= as, CA 95035

=A0

Hampton Inn = Milpitas=A0 (408) 428-9090

215 Ba= rber Court

Milpitas, CA= 95035

=A0<= /p>


--f46d040839195bfef904c7409530-- From apeppere@gmail.com Wed Aug 15 00:48: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 C5B8F21F86FA for ; Wed, 15 Aug 2012 00:48:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.512 X-Spam-Level: X-Spam-Status: No, score=-2.512 tagged_above=-999 required=5 tests=[AWL=-0.580, BAYES_00=-2.599, 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 tArK8k9XVENi for ; Wed, 15 Aug 2012 00:48:09 -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 979DB21F86F4 for ; Wed, 15 Aug 2012 00:48:06 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so1428080vcb.31 for ; Wed, 15 Aug 2012 00:48: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; bh=WPE0/y4hGyh9fVSA/15SlMW+Bog/yt3/xha276MNumA=; b=tzwnDLeVtTdx0pgJGeduyMU/quedUn7BCDwiry/I7LDQ7xYJjB27vb/Nln1lKlh8Ks Tc9LyOWzGY0YQQVH565xbKulU7D+6ox2fGzhSnBv+wbrf3Ncm+JPnme9lh5nCzyWl6MZ ROjC3UUV1/qwFlrq3kxz8fec6lSgE+0O8LLh1y6w49d4C2NoR/gVS7i/Fm0EpAk+Zon7 FuQvxq4iQZbjgY1tJB00MLoYYkjGnQlASp5PyMNN7wLsddzfsCvNi9h2RnnO3bnO5vGv uNOdbs4fISUEoMAnZ6c2ivELW00JUwHiy6y4hWQZbJLj5kLgkRw4zTYmZ7GXLeNcGUlP Hz1Q== MIME-Version: 1.0 Received: by 10.220.218.133 with SMTP id hq5mr12278807vcb.60.1345016883406; Wed, 15 Aug 2012 00:48:03 -0700 (PDT) Received: by 10.220.194.134 with HTTP; Wed, 15 Aug 2012 00:48:03 -0700 (PDT) In-Reply-To: <502AB7B1.4070506@alum.mit.edu> References: <068.5ca029063d5e7080dd9f9169d703adcf@trac.tools.ietf.org> <7F2072F1E0DE894DA4B517B93C6A0585340868365E@ESESSCMS0356.eemea.ericsson.se> <005201cd7a62$40e62260$c2b26720$@gmail.com> <502AB7B1.4070506@alum.mit.edu> Date: Wed, 15 Aug 2012 08:48:03 +0100 Message-ID: From: Andy Pepperell To: christer.holmberg@ericsson.com Content-Type: multipart/alternative; boundary=14dae9cfc7708d662e04c74925f1 Cc: clue@ietf.org Subject: Re: [clue] Fwd: #11: RTP header extension for Capture ID 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, 15 Aug 2012 07:48:10 -0000 --14dae9cfc7708d662e04c74925f1 Content-Type: text/plain; charset=ISO-8859-1 Hi Christer, >Is there a reason why we can't use the SSRC? Or, can multiple captures share the same SSRC? I don't think I'm disagreeing here with anything that Roni or Paul are saying, but was thinking that the phrase "use the SSRC" potentially covers a few different cases... - If we're talking about declaring SSRC values in advance in SDP, this is likely to cause scalability issues with CLUE (more so than with, say, current webrtc implementations) because of the potential for a large number of CLUE streams in MCU cases. - The current RTP header extension proposal involves the consumer telling the provider an ID to use in the RTP header extension for each instantiated capture, which the consumer can then use to separate the multiple capture instantiations when they are received. It would clearly be reasonably straightforward for the CLUE consumer stream choice message to instead indicate an SSRC here instead of an ID to be put in an RTP header extension, but as Paul points out, this means that the consumer then loses the ability to distinguish stream changes within a switched capture (modulo CSRC usage). >[Paul] >For instance, for the switched case it would then be necessary to assign an ssrc for the switched capture... Agreed, though I think the SSRC assignment would have to be on the basis of the switched capture's *instantiation* rather than the switched capture itself - with the simulcast aspects of CLUE as currently defined, mappings can't be on the basis of just capture IDs as a consumer may request multiple instantiations of the same capture from the provider, and so a simple SSRC <--> capture ID mapping would not be sufficient. Regards, Andy On Tue, Aug 14, 2012 at 9:40 PM, Paul Kyzivat wrote: > On 8/14/12 5:17 PM, Roni Even wrote: > >> Hi Christer, >> This works for static SSRCs when the mixer uses its own SSRC. The problem >> is >> in the switching case when using the source SSRC. An example is when a >> three >> camera system has two captures to send to a two monitor system. The three >> camera system may send first the left and center camera but when switching >> to center and right camera the center camera will switch from right >> capture >> to left capture. >> This was discussed in my presentation in CLUE about mapping RTP streams. >> > > AFAIK it *could* work using SSRC. But then there are different constraints > on how RTP is used. > > For instance, for the switched case it would then be necessary to assign > an ssrc for the switched capture, and indicate the source via csrc. > > It also then means that if a source is moved from one switched capture to > a different one, the recipient won't know that it is the *same* RTP stream. > And that affects the number of iframes transmitted, etc. > > tradeoffs! > > Thanks, > Paul > > > Roni >> >> -----Original Message----- >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of >> Christer Holmberg >> Sent: 14 August, 2012 9:38 PM >> To: Mary Barnes; CLUE >> Subject: Re: [clue] Fwd: #11: RTP header extension for Capture ID >> >> Hi, >> >> A silly question: >> >> Is there a reason why we can't use the SSRC? Or, can multiple captures >> share >> the same SSRC? >> >> Regards, >> >> Christer >> >> ______________________________**__ >> From: clue-bounces@ietf.org [clue-bounces@ietf.org] On Behalf Of Mary >> Barnes >> [mary.ietf.barnes@gmail.com] >> Sent: Monday, August 13, 2012 10:37 PM >> To: CLUE >> Subject: [clue] Fwd: #11: RTP header extension for Capture ID >> >> Hi all, >> >> I have updated/closed the issues as discussed at the meeting (and captured >> in the minutes): http://www.ietf.org/**proceedings/84/minutes/** >> minutes-84-clue >> >> I decided to open a ticket to track this issue since it does require some >> mailing list discussion and hopefully, this will trigger that. >> >> The action items from the meeting that are not related to issues are >> updates >> to documents - i.e., new data model document and adding telemedical use >> case >> to the WG use case document. >> >> Mary. >> >> ---------- Forwarded message ---------- >> From: clue issue tracker >> >> >> >> Date: Mon, Aug 13, 2012 at 2:33 PM >> Subject: [clue] #11: RTP header extension for Capture ID >> To: clue-chairs@tools.ietf.org<**mailto:clue-chairs@tools.ietf.**org >> >, >> mary.ietf.barnes@gmail.com<**mailto:mary.ietf.barnes@gmail.**com >> > >> Cc: clue@ietf.org> >> >> >> #11: RTP header extension for Capture ID >> >> Is an RTP header extension needed to transport a capture ID (per draft- >> lennox-clue-rtp-usage-04)? >> >> -- >> ------------------------------**-----+------------------------**--- >> Reporter: mary.ietf.barnes@. | Owner: clue-chairs@. >> Type: defect | Status: new >> Priority: major | Milestone: milestone1 >> Component: charter | Version: 1.0 >> Severity: Candidate WG Document | Keywords: RTP >> ------------------------------**-----+------------------------**--- >> >> Ticket URL: >> > >> 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 > --14dae9cfc7708d662e04c74925f1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Christer,

>Is there a reason why we can't= use the SSRC? Or, can multiple captures share=A0the same SSRC?
<= br>
I don't think I'm disagreeing here with anything that= Roni or Paul are saying, but was thinking that the phrase "use the SS= RC" potentially covers a few different cases...

- If we're talking about declaring SSRC values in a= dvance in SDP, this is likely to cause scalability issues with CLUE (more s= o than with, say, current webrtc implementations) because of the potential = for a large number of CLUE streams in MCU cases.

- The current RTP header extension proposal involves th= e consumer telling the provider an ID to use in the RTP header extension fo= r each instantiated capture, which the consumer can then use to separate th= e multiple capture instantiations when they are received. It would clearly = be reasonably straightforward for the CLUE consumer stream choice message t= o instead indicate an SSRC here instead of an ID to be put in an RTP header= extension, but as Paul points out, this means that the consumer then loses= the ability to distinguish stream changes within a switched capture (modul= o CSRC usage).

>[Paul]
>For instance, for the switched= case it would then be necessary to assign an ssrc for the switched capture= ...

Agreed, though I think the SSRC assignment= would have to be on the basis of the switched capture's *instantiation= * rather than the switched capture itself - with=A0the simulcast aspects of= CLUE as currently defined, mappings can't be on the basis of just capt= ure IDs as a consumer may request multiple instantiations of the same captu= re from the provider, and so a simple SSRC <--> capture ID mapping wo= uld not be sufficient.

Regards,

Andy


On Tue, Aug 14, 2012 at 9:40 PM, Paul Ky= zivat <pkyzivat@alum.mit.edu> wrote:
On 8/14/12 5:17 PM, Roni E= ven wrote:
Hi Christer,
This works for static SSRCs when the mixer uses its own SSRC. The problem i= s
in the switching case when using the source SSRC. An example is when a thre= e
camera system has two captures to send to a two monitor system. The three camera system may send first the left and center camera but when switching<= br> to center and right camera the center camera will switch from right capture=
to left capture.
This was discussed in my presentation in CLUE about mapping RTP streams.

AFAIK it *could* work using SSRC. But then there are different constraints = on how RTP is used.

For instance, for the switched case it would then be necessary to assign an= ssrc for the switched capture, and indicate the source via csrc.

It also then means that if a source is moved from one switched capture to a= different one, the recipient won't know that it is the *same* RTP stre= am. And that affects the number of iframes transmitted, etc.

tradeoffs!

=A0 =A0 =A0 =A0 Thanks,
=A0 =A0 =A0 =A0 Paul


Roni

-----Original Message-----
From: clue-bounc= es@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of
Christer Holmberg
Sent: 14 August, 2012 9:38 PM
To: Mary Barnes; CLUE
Subject: Re: [clue] Fwd: #11: RTP header extension for Capture ID

Hi,

A silly question:

Is there a reason why we can't use the SSRC? Or, can multiple captures = share
the same SSRC?

Regards,

Christer

________________________________
From: clue-bounc= es@ietf.org [clue-bounces@ietf.org] On Behalf Of Mary Barnes
[mary.ietf.= barnes@gmail.com]
Sent: Monday, August 13, 2012 10:37 PM
To: CLUE
Subject: [clue] Fwd: #11: RTP header extension for Capture ID

Hi all,

I have updated/closed the issues as discussed at the meeting (and captured<= br> in the minutes): =A0http://www.ietf.org/proceedings/84= /minutes/minutes-84-clue

I decided to open a ticket to track this issue since it does require some mailing list discussion and hopefully, this will trigger that.

The action items from the meeting that are not related to issues are update= s
to documents - i.e., new data model document and adding telemedical use cas= e
to the WG use case document.

Mary.

---------- Forwarded message ----------
From: clue issue tracker
<tr= ac+clue@trac.tools.ietf.org<mailto:trac%2Bclue@trac.tools.= ietf.org>>
Date: Mon, Aug 13, 2012 at 2:33 PM
Subject: [clue] #11: RTP header extension for Capture ID
To: clue-ch= airs@tools.ietf.org<mailto:clue-chairs@tools.ietf.org>, mary.ietf.b= arnes@gmail.com<mailto:mary.ietf.barnes@gmail.com>
Cc: clue@ietf.org<= ;mailto:clue@ietf= .org>


#11: RTP header extension for Capture ID

=A0 Is an RTP header extension needed to transport a capture ID (per draft-=
lennox-clue-rtp-usage-04)?

--
-----------------------------------+-------------------------= --
=A0 Reporter: =A0mary.ietf.barnes@. =A0 =A0 | =A0 =A0 =A0Owner: =A0clue-cha= irs@.
=A0 =A0 =A0 Type: =A0defect =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 Statu= s: =A0new
=A0 Priority: =A0major =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0Milestone: = =A0milestone1
Component: =A0charter =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0Version: =A01= .0
=A0 Severity: =A0Candidate WG Document =A0| =A0 Keywords: =A0RTP
-----------------------------------+-------------------------= --

Ticket URL:<http://grenache.tools.ietf.org/wg/clue/trac/= ticket/11>
clue<http:/= /tools.ietf.org/wg/clue/>


_______________________________________________
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


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

--14dae9cfc7708d662e04c74925f1-- From ron.even.tlv@gmail.com Wed Aug 15 01:21: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 91A4321F86F2 for ; Wed, 15 Aug 2012 01:21:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uk6A+dcVw9hE for ; Wed, 15 Aug 2012 01:21:09 -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 C89E721F8742 for ; Wed, 15 Aug 2012 01:21:08 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so784017wgb.13 for ; Wed, 15 Aug 2012 01:21:05 -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:x-mailer:thread-index:content-language; bh=4nCk79fr4Wf0aHDs1lQTQEwhj+kK94npU0fXaQhGkZ4=; b=E5gFXDLmOr5LA4xoZnsUDwZQ39UrMYR3x+W7VJbBpJbUzQjuBFUboM2ovLmTBU+0NO mOrBzu8kcpT5gqzM3sjLbzBvYRbTVtloEoPjt0vcaEOYta5xalFskgVRo6jJaOzzOoY8 GGp+RCrBa4qssHD3oi72XaE5SqFmf/csgS1AN358wXHSP57hV0AXOaIr4e6RuljKzxLw o95EGD9bOGk4NA6coYrNruE6p8dOFIwp2i+CVndpHmchH57gUbO6qzqt65Orw7aFYQA8 2bjBGo3U5+Hjvv39+U89lg0vtOTxoJjh/tbk3Z5/NVXYfb+szV1eOAStq2/wiFJBOKc8 qdzg== Received: by 10.216.243.74 with SMTP id j52mr9229427wer.108.1345018865389; Wed, 15 Aug 2012 01:21:05 -0700 (PDT) Received: from RoniE (bzq-79-181-195-163.red.bezeqint.net. [79.181.195.163]) by mx.google.com with ESMTPS id el6sm27218300wib.8.2012.08.15.01.21.01 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 15 Aug 2012 01:21:04 -0700 (PDT) From: "Roni Even" To: "'Andy Pepperell'" , References: <068.5ca029063d5e7080dd9f9169d703adcf@trac.tools.ietf.org> <7F2072F1E0DE894DA4B517B93C6A0585340868365E@ESESSCMS0356.eemea.ericsson.se> <005201cd7a62$40e62260$c2b26720$@gmail.com> <502AB7B1.4070506@alum.mit.edu> In-Reply-To: Date: Wed, 15 Aug 2012 11:19:51 +0200 Message-ID: <003901cd7ac7$22323a10$6696ae30$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_003A_01CD7AD7.E5BCB7C0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFM/VlsLWUUBwuvWjT5seMrvYeAmQJvL0GbAjiJEHMBkpDbuQJNqn6UAo7Cq92YAt2cAA== Content-Language: en-us Cc: clue@ietf.org Subject: Re: [clue] Fwd: #11: RTP header extension for Capture ID 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, 15 Aug 2012 08:21:10 -0000 This is a multipart message in MIME format. ------=_NextPart_000_003A_01CD7AD7.E5BCB7C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Andy, I fail to understand why the consumer needs to define the mapping ID for a mapping done by the provider Roni From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Andy Pepperell Sent: 15 August, 2012 9:48 AM To: christer.holmberg@ericsson.com Cc: clue@ietf.org Subject: Re: [clue] Fwd: #11: RTP header extension for Capture ID Hi Christer, >Is there a reason why we can't use the SSRC? Or, can multiple captures share the same SSRC? I don't think I'm disagreeing here with anything that Roni or Paul are saying, but was thinking that the phrase "use the SSRC" potentially covers a few different cases... - If we're talking about declaring SSRC values in advance in SDP, this is likely to cause scalability issues with CLUE (more so than with, say, current webrtc implementations) because of the potential for a large number of CLUE streams in MCU cases. - The current RTP header extension proposal involves the consumer telling the provider an ID to use in the RTP header extension for each instantiated capture, which the consumer can then use to separate the multiple capture instantiations when they are received. It would clearly be reasonably straightforward for the CLUE consumer stream choice message to instead indicate an SSRC here instead of an ID to be put in an RTP header extension, but as Paul points out, this means that the consumer then loses the ability to distinguish stream changes within a switched capture (modulo CSRC usage). >[Paul] >For instance, for the switched case it would then be necessary to assign an ssrc for the switched capture... Agreed, though I think the SSRC assignment would have to be on the basis of the switched capture's *instantiation* rather than the switched capture itself - with the simulcast aspects of CLUE as currently defined, mappings can't be on the basis of just capture IDs as a consumer may request multiple instantiations of the same capture from the provider, and so a simple SSRC <--> capture ID mapping would not be sufficient. Regards, Andy On Tue, Aug 14, 2012 at 9:40 PM, Paul Kyzivat wrote: On 8/14/12 5:17 PM, Roni Even wrote: Hi Christer, This works for static SSRCs when the mixer uses its own SSRC. The problem is in the switching case when using the source SSRC. An example is when a three camera system has two captures to send to a two monitor system. The three camera system may send first the left and center camera but when switching to center and right camera the center camera will switch from right capture to left capture. This was discussed in my presentation in CLUE about mapping RTP streams. AFAIK it *could* work using SSRC. But then there are different constraints on how RTP is used. For instance, for the switched case it would then be necessary to assign an ssrc for the switched capture, and indicate the source via csrc. It also then means that if a source is moved from one switched capture to a different one, the recipient won't know that it is the *same* RTP stream. And that affects the number of iframes transmitted, etc. tradeoffs! Thanks, Paul Roni -----Original Message----- From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Christer Holmberg Sent: 14 August, 2012 9:38 PM To: Mary Barnes; CLUE Subject: Re: [clue] Fwd: #11: RTP header extension for Capture ID Hi, A silly question: Is there a reason why we can't use the SSRC? Or, can multiple captures share the same SSRC? Regards, Christer ________________________________ From: clue-bounces@ietf.org [clue-bounces@ietf.org] On Behalf Of Mary Barnes [mary.ietf.barnes@gmail.com] Sent: Monday, August 13, 2012 10:37 PM To: CLUE Subject: [clue] Fwd: #11: RTP header extension for Capture ID Hi all, I have updated/closed the issues as discussed at the meeting (and captured in the minutes): http://www.ietf.org/proceedings/84/minutes/minutes-84-clue I decided to open a ticket to track this issue since it does require some mailing list discussion and hopefully, this will trigger that. The action items from the meeting that are not related to issues are updates to documents - i.e., new data model document and adding telemedical use case to the WG use case document. Mary. ---------- Forwarded message ---------- From: clue issue tracker >> Date: Mon, Aug 13, 2012 at 2:33 PM Subject: [clue] #11: RTP header extension for Capture ID To: clue-chairs@tools.ietf.org, mary.ietf.barnes@gmail.com Cc: clue@ietf.org #11: RTP header extension for Capture ID Is an RTP header extension needed to transport a capture ID (per draft- lennox-clue-rtp-usage-04)? -- -----------------------------------+--------------------------- Reporter: mary.ietf.barnes@. | Owner: clue-chairs@. Type: defect | Status: new Priority: major | Milestone: milestone1 Component: charter | Version: 1.0 Severity: Candidate WG Document | Keywords: RTP -----------------------------------+--------------------------- Ticket URL: 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 ------=_NextPart_000_003A_01CD7AD7.E5BCB7C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Andy,

I fail to understand why the consumer needs to define the mapping ID = for a mapping done by the provider

Roni

 

From:= = clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of = Andy Pepperell
Sent: 15 August, 2012 9:48 AM
To: = christer.holmberg@ericsson.com
Cc: = clue@ietf.org
Subject: Re: [clue] Fwd: #11: RTP header = extension for Capture ID

 

Hi = Christer,

 

>Is there a reason why we can't use the SSRC? Or, = can multiple captures share the same = SSRC?

 

I = don't think I'm disagreeing here with anything that Roni or Paul are = saying, but was thinking that the phrase "use the SSRC" = potentially covers a few different cases...

 

- = If we're talking about declaring SSRC values in advance in SDP, this is = likely to cause scalability issues with CLUE (more so than with, say, = current webrtc implementations) because of the potential for a large = number of CLUE streams in MCU cases.

 

- = The current RTP header extension proposal involves the consumer telling = the provider an ID to use in the RTP header extension for each = instantiated capture, which the consumer can then use to separate the = multiple capture instantiations when they are received. It would clearly = be reasonably straightforward for the CLUE consumer stream choice = message to instead indicate an SSRC here instead of an ID to be put in = an RTP header extension, but as Paul points out, this means that the = consumer then loses the ability to distinguish stream changes within a = switched capture (modulo CSRC usage).

 

>[Paul]

>For instance, for the switched case it would then = be necessary to assign an ssrc for the switched = capture...

 

Agreed, though I think the SSRC assignment would have = to be on the basis of the switched capture's *instantiation* rather than = the switched capture itself - with the simulcast aspects of CLUE as = currently defined, mappings can't be on the basis of just capture IDs as = a consumer may request multiple instantiations of the same capture from = the provider, and so a simple SSRC <--> capture ID mapping would = not be sufficient.

 

Regards,

 

Andy

 

 

On Tue, = Aug 14, 2012 at 9:40 PM, Paul Kyzivat <pkyzivat@alum.mit.edu> = wrote:

On 8/14/12 5:17 PM, Roni = Even wrote:

Hi Christer,
This = works for static SSRCs when the mixer uses its own SSRC. The problem = is
in the switching case when using the source SSRC. An example is = when a three
camera system has two captures to send to a two monitor = system. The three
camera system may send first the left and center = camera but when switching
to center and right camera the center = camera will switch from right capture
to left capture.
This was = discussed in my presentation in CLUE about mapping RTP = streams.

 

AFAIK = it *could* work using SSRC. But then there are different constraints on = how RTP is used.

For instance, for the switched case it would = then be necessary to assign an ssrc for the switched capture, and = indicate the source via csrc.

It also then means that if a source = is moved from one switched capture to a different one, the recipient = won't know that it is the *same* RTP stream. And that affects the number = of iframes transmitted, etc.

tradeoffs!

    =     Thanks,
        = Paul

 

Roni

-----Original = Message-----
From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of
Christer = Holmberg
Sent: 14 August, 2012 9:38 PM
To: Mary Barnes; = CLUE
Subject: Re: [clue] Fwd: #11: RTP header extension for Capture = ID

Hi,

A silly question:

Is there a reason why we = can't use the SSRC? Or, can multiple captures share
the same = SSRC?

Regards,

Christer

____________________________= ____
From: clue-bounces@ietf.org [clue-bounces@ietf.org] On Behalf Of Mary = Barnes
[mary.ietf.barnes@gmail.com]
Sent: Monday, = August 13, 2012 10:37 PM
To: CLUE
Subject: [clue] Fwd: #11: RTP = header extension for Capture ID

Hi all,

I have = updated/closed the issues as discussed at the meeting (and = captured
in the minutes):  http://www.ietf.org/proceedings/84/minutes/minutes-84-c= lue

I decided to open a ticket to track this issue since it = does require some
mailing list discussion and hopefully, this will = trigger that.

The action items from the meeting that are not = related to issues are updates
to documents - i.e., new data model = document and adding telemedical use case
to the WG use case = document.

Mary.

---------- Forwarded message = ----------
From: clue issue tracker
<trac+clue@trac.tools.ietf.org<mailto:trac%2Bclue@trac.tools.ietf.org>>
Date: = Mon, Aug 13, 2012 at 2:33 PM
Subject: [clue] #11: RTP header = extension for Capture ID
To: clue-chairs@tools.ietf.org<mailto:clue-chairs@tools.ietf.org>,
mary.ietf.barnes@gmail.com<mailto:mary.ietf.barnes@gmail.com>
Cc: clue@ietf.org<mailto:clue@ietf.org>


#11: RTP header = extension for Capture ID

  Is an RTP header extension needed = to transport a capture ID (per = draft-
lennox-clue-rtp-usage-04)?

--
-----------------------= ------------+---------------------------
  Reporter:  mary.ietf.barnes@.     | =      Owner:  clue-chairs@.
      = Type:  defect               =   |     Status:  new
  Priority:  major =                  | =  Milestone:  milestone1
Component:  charter   =              |    Version: =  1.0
  Severity:  Candidate WG Document  |   = Keywords: =  RTP
-----------------------------------+------------------------= ---

Ticket URL:<http://grenache.tools.ietf.org/wg/clue/trac/ticket/11>
clue<http://tools.ietf.org/wg/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

 

------=_NextPart_000_003A_01CD7AD7.E5BCB7C0-- From apeppere@gmail.com Wed Aug 15 01:58:02 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 6D69321F875D for ; Wed, 15 Aug 2012 01:58:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.273 X-Spam-Level: X-Spam-Status: No, score=-3.273 tagged_above=-999 required=5 tests=[AWL=0.325, 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 uj0LB115GVKd for ; Wed, 15 Aug 2012 01:58:01 -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 09C1221F875A for ; Wed, 15 Aug 2012 01:58:00 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so1482383vcb.31 for ; Wed, 15 Aug 2012 01:58:00 -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=3f6L54cwsEiZ60afOD/xBcq1JpCiOZ45B07jiq95qeU=; b=HLC4zhJj7TiuEDj2CJMYeHXj8pfofI69uK+3kGlvHEP86WGW4BCTDj2hYauFh+lhca 7PDgoPvf8FVgevXbZ8qdiXulu/rp1e35qmBcPFzIkpPC+78MgAn3V1NihEPJAieYxrxo 5Pq5GsQd6KajSkCkicTC5RcgWNA5veh9GFueEvuc5OamfVxgd26JcHqMvOIaxW5XXxe9 z1SRV8B7WjYrYEiCcN0Ocq8EiMO5scpt+BSFQF5SLOXj94A2BLI8nei2vGvirXcn0KJx 4BzAnqks03GetxbdB3o4ocHopk6CbJ5jxAHr2jwrqCFYZJa8mb/Ytky68HHTc9yT2wJL bVmw== MIME-Version: 1.0 Received: by 10.59.8.37 with SMTP id dh5mr14168410ved.2.1345021056552; Wed, 15 Aug 2012 01:57:36 -0700 (PDT) Received: by 10.220.194.134 with HTTP; Wed, 15 Aug 2012 01:57:36 -0700 (PDT) In-Reply-To: <003901cd7ac7$22323a10$6696ae30$@gmail.com> References: <068.5ca029063d5e7080dd9f9169d703adcf@trac.tools.ietf.org> <7F2072F1E0DE894DA4B517B93C6A0585340868365E@ESESSCMS0356.eemea.ericsson.se> <005201cd7a62$40e62260$c2b26720$@gmail.com> <502AB7B1.4070506@alum.mit.edu> <003901cd7ac7$22323a10$6696ae30$@gmail.com> Date: Wed, 15 Aug 2012 09:57:36 +0100 Message-ID: From: Andy Pepperell To: Roni Even Content-Type: multipart/alternative; boundary=047d7bdc926a4a8f1c04c74a1eb2 Cc: clue@ietf.org Subject: Re: [clue] Fwd: #11: RTP header extension for Capture ID 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, 15 Aug 2012 08:58:02 -0000 --047d7bdc926a4a8f1c04c74a1eb2 Content-Type: text/plain; charset=ISO-8859-1 Hi Roni, I'm not sure I understand the point - are you asking why the consumer is assigning the IDs rather than the provider? or, taking it further, are you proposing that the provider allocate the IDs? Andy On Wed, Aug 15, 2012 at 10:19 AM, Roni Even wrote: > Andy,**** > > I fail to understand why the consumer needs to define the mapping ID for a > mapping done by the provider**** > > Roni**** > > ** ** > > *From:* clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On Behalf > Of *Andy Pepperell > *Sent:* 15 August, 2012 9:48 AM > *To:* christer.holmberg@ericsson.com > *Cc:* clue@ietf.org > > *Subject:* Re: [clue] Fwd: #11: RTP header extension for Capture ID**** > > ** ** > > Hi Christer,**** > > ** ** > > >Is there a reason why we can't use the SSRC? Or, can multiple captures > share the same SSRC?**** > > ** ** > > I don't think I'm disagreeing here with anything that Roni or Paul are > saying, but was thinking that the phrase "use the SSRC" potentially covers > a few different cases...**** > > ** ** > > - If we're talking about declaring SSRC values in advance in SDP, this is > likely to cause scalability issues with CLUE (more so than with, say, > current webrtc implementations) because of the potential for a large number > of CLUE streams in MCU cases.**** > > ** ** > > - The current RTP header extension proposal involves the consumer telling > the provider an ID to use in the RTP header extension for each instantiated > capture, which the consumer can then use to separate the multiple capture > instantiations when they are received. It would clearly be reasonably > straightforward for the CLUE consumer stream choice message to instead > indicate an SSRC here instead of an ID to be put in an RTP header > extension, but as Paul points out, this means that the consumer then loses > the ability to distinguish stream changes within a switched capture (modulo > CSRC usage).**** > > ** ** > > >[Paul]**** > > >For instance, for the switched case it would then be necessary to assign > an ssrc for the switched capture...**** > > ** ** > > Agreed, though I think the SSRC assignment would have to be on the basis > of the switched capture's *instantiation* rather than the switched capture > itself - with the simulcast aspects of CLUE as currently defined, mappings > can't be on the basis of just capture IDs as a consumer may request > multiple instantiations of the same capture from the provider, and so a > simple SSRC <--> capture ID mapping would not be sufficient.**** > > ** ** > > Regards,**** > > ** ** > > Andy**** > > ** ** > > ** ** > > On Tue, Aug 14, 2012 at 9:40 PM, Paul Kyzivat > wrote:**** > > On 8/14/12 5:17 PM, Roni Even wrote:**** > > Hi Christer, > This works for static SSRCs when the mixer uses its own SSRC. The problem > is > in the switching case when using the source SSRC. An example is when a > three > camera system has two captures to send to a two monitor system. The three > camera system may send first the left and center camera but when switching > to center and right camera the center camera will switch from right capture > to left capture. > This was discussed in my presentation in CLUE about mapping RTP streams.** > ** > > ** ** > > AFAIK it *could* work using SSRC. But then there are different constraints > on how RTP is used. > > For instance, for the switched case it would then be necessary to assign > an ssrc for the switched capture, and indicate the source via csrc. > > It also then means that if a source is moved from one switched capture to > a different one, the recipient won't know that it is the *same* RTP stream. > And that affects the number of iframes transmitted, etc. > > tradeoffs! > > Thanks, > Paul**** > > ** ** > > Roni > > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Christer Holmberg > Sent: 14 August, 2012 9:38 PM > To: Mary Barnes; CLUE > Subject: Re: [clue] Fwd: #11: RTP header extension for Capture ID > > Hi, > > A silly question: > > Is there a reason why we can't use the SSRC? Or, can multiple captures > share > the same SSRC? > > Regards, > > Christer > > ________________________________ > From: clue-bounces@ietf.org [clue-bounces@ietf.org] On Behalf Of Mary > Barnes > [mary.ietf.barnes@gmail.com] > Sent: Monday, August 13, 2012 10:37 PM > To: CLUE > Subject: [clue] Fwd: #11: RTP header extension for Capture ID > > Hi all, > > I have updated/closed the issues as discussed at the meeting (and captured > in the minutes): > http://www.ietf.org/proceedings/84/minutes/minutes-84-clue > > I decided to open a ticket to track this issue since it does require some > mailing list discussion and hopefully, this will trigger that. > > The action items from the meeting that are not related to issues are > updates > to documents - i.e., new data model document and adding telemedical use > case > to the WG use case document. > > Mary. > > ---------- Forwarded message ---------- > From: clue issue tracker > > > Date: Mon, Aug 13, 2012 at 2:33 PM > Subject: [clue] #11: RTP header extension for Capture ID > To: clue-chairs@tools.ietf.org, > mary.ietf.barnes@gmail.com > Cc: clue@ietf.org > > > #11: RTP header extension for Capture ID > > Is an RTP header extension needed to transport a capture ID (per draft- > lennox-clue-rtp-usage-04)? > > -- > -----------------------------------+--------------------------- > Reporter: mary.ietf.barnes@. | Owner: clue-chairs@. > Type: defect | Status: new > Priority: major | Milestone: milestone1 > Component: charter | Version: 1.0 > Severity: Candidate WG Document | Keywords: RTP > -----------------------------------+--------------------------- > > Ticket URL: > 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**** > > ** ** > --047d7bdc926a4a8f1c04c74a1eb2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Roni,

I'm not sure I understand the point - are y= ou asking why the consumer is assigning the IDs rather than the provider? o= r, taking it further, are you proposing that the provider allocate the IDs?=

Andy


On We= d, Aug 15, 2012 at 10:19 AM, Roni Even <ron.even.tlv@gmail.com>= ; wrote:

Andy,<= u>

I fail to understand why = the consumer needs to define the mapping ID for a mapping done by the provi= der

Roni=

=A0

From: clue-bounces@ietf.org [mailto:clue-= bounces@ietf.org] On Behalf Of Andy Pepperell
Sent: 15 August, 2012 9:48 AM
To: christer.holmberg@ericsson.com<= /a>
Cc: clue@i= etf.org


Subject: Re: [clue] Fwd: #11: RTP header = extension for Capture ID

=A0

Hi = Christer,

=A0

>Is there a reason why we can't use the SSRC? Or, can= multiple captures share=A0the same SSRC?

=A0

I don't think I&= #39;m disagreeing here with anything that Roni or Paul are saying, but was = thinking that the phrase "use the SSRC" potentially covers a few = different cases...

=A0

- If we're talking about declaring SSRC values in advanc= e in SDP, this is likely to cause scalability issues with CLUE (more so tha= n with, say, current webrtc implementations) because of the potential for a= large number of CLUE streams in MCU cases.

=A0

- The current RTP header extension proposal involves the con= sumer telling the provider an ID to use in the RTP header extension for eac= h instantiated capture, which the consumer can then use to separate the mul= tiple capture instantiations when they are received. It would clearly be re= asonably straightforward for the CLUE consumer stream choice message to ins= tead indicate an SSRC here instead of an ID to be put in an RTP header exte= nsion, but as Paul points out, this means that the consumer then loses the = ability to distinguish stream changes within a switched capture (modulo CSR= C usage).

=A0

>[Paul]

>For instance, for the switched case it would then be necessary to ass= ign an ssrc for the switched capture...

=A0

Agreed, though I think the SSRC assignment would have to be = on the basis of the switched capture's *instantiation* rather than the = switched capture itself - with=A0the simulcast aspects of CLUE as currently= defined, mappings can't be on the basis of just capture IDs as a consu= mer may request multiple instantiations of the same capture from the provid= er, and so a simple SSRC <--> capture ID mapping would not be suffici= ent.

=A0

Regards,

= =A0

Andy

=A0

=A0

On Tue, Aug 14, 2012 at 9:40= PM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:

On 8/14/12 5:17 PM, Roni Even wrote:<= /u>

Hi Christer,
This works for static SSRCs w= hen the mixer uses its own SSRC. The problem is
in the switching case wh= en using the source SSRC. An example is when a three
camera system has two captures to send to a two monitor system. The threecamera system may send first the left and center camera but when switchin= g
to center and right camera the center camera will switch from right ca= pture
to left capture.
This was discussed in my presentation in CLUE about map= ping RTP streams.

=A0=

AFAIK it *could* work using SSRC. But then= there are different constraints on how RTP is used.

For instance, for the switched case it would then be necessary to assig= n an ssrc for the switched capture, and indicate the source via csrc.
It also then means that if a source is moved from one switched capture to= a different one, the recipient won't know that it is the *same* RTP st= ream. And that affects the number of iframes transmitted, etc.

tradeoffs!

=A0 =A0 =A0 =A0 Thanks,
=A0 =A0 =A0 =A0 Paul

<= p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"> =A0

= Roni

-----Original Message-----
From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of
Christer Holmberg
Sent: 14 August, 2012 9:38 PM
To: Mary Barnes; CLUE=
Subject: Re: [clue] Fwd: #11: RTP header extension for Capture ID
Hi,

A silly question:

Is there a reason why we can't us= e the SSRC? Or, can multiple captures share
the same SSRC?

Regards,

Christer

_____________________= ___________
From: clue-bounces@ietf.org [clue-bounces@ietf.org] On Behalf Of Mary Barnes
[mary.ietf.= barnes@gmail.com]
Sent: Monday, August 13, 2012 10:37 PM
To: CLUE=
Subject: [clue] Fwd: #11: RTP header extension for Capture ID

Hi= all,

I have updated/closed the issues as discussed at the meeting (and captu= red
in the minutes): =A0http://www.ietf.org/proceedings/84= /minutes/minutes-84-clue

I decided to open a ticket to track this issue since it does require so= me
mailing list discussion and hopefully, this will trigger that.
The action items from the meeting that are not related to issues are updat= es
to documents - i.e., new data model document and adding telemedical use cas= e
to the WG use case document.

Mary.

---------- Forwarded = message ----------
From: clue issue tracker
<trac+clue@trac.tools.ietf.o= rg<mailto:trac%2Bclue@trac.tools.ietf.org>>
Date: Mon, Aug 13, 2012 at 2:33 PM
Subject: [clue] #11: RTP header exten= sion for Capture ID
To: clue-chairs@tools.ietf.org<mailto:clue-chairs@tools.ietf.org>,
mary.ietf.b= arnes@gmail.com<mailto:mary.ietf.barnes@gmail.com>
Cc: clue@ietf.org<mailto:clue@ietf.org>


#11: RTP header extension for Capture ID

=A0 Is an RTP heade= r extension needed to transport a capture ID (per draft-
lennox-clue-rtp= -usage-04)?

--
-----------------------------------+--------------= -------------
=A0 Reporter: =A0mar= y.ietf.barnes@. =A0 =A0 | =A0 =A0 =A0Owner: =A0clue-chairs@.
=A0 =A0= =A0 Type: =A0defect =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 Status: =A0n= ew
=A0 Priority: =A0major =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0Milest= one: =A0milestone1
Component: =A0charter =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0Version: =A01= .0
=A0 Severity: =A0Candidate WG Document =A0| =A0 Keywords: =A0RTP
-= ----------------------------------+---------------------------

Ticke= t URL:<http://grenache.tools.ietf.org/wg/clue/trac/ticket/11>
clue<http:/= /tools.ietf.org/wg/clue/>


_______________________________= ________________
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

=


_______________________________________________<= br> clue mailing list
clu= e@ietf.org
https://www.ietf.org/mailman/listinfo/clue

=A0

<= /div>

--047d7bdc926a4a8f1c04c74a1eb2-- From Even.roni@huawei.com Wed Aug 15 02:50: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 81DEA21F879D for ; Wed, 15 Aug 2012 02:50:31 -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, HTML_MESSAGE=0.001, 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 AIdSHC50mJOt for ; Wed, 15 Aug 2012 02:50:30 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id B7F1421F8782 for ; Wed, 15 Aug 2012 02:50:29 -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 AIW82234; Wed, 15 Aug 2012 01:50:29 -0800 (PST) Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 15 Aug 2012 02:48:34 -0700 Received: from SZXEML429-HUB.china.huawei.com (10.72.61.37) by dfweml403-hub.china.huawei.com (10.193.5.151) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 15 Aug 2012 02:48:37 -0700 Received: from SZXEML536-MBX.china.huawei.com ([10.82.67.115]) by SZXEML429-HUB.china.huawei.com ([10.72.61.37]) with mapi id 14.01.0323.003; Wed, 15 Aug 2012 17:48:32 +0800 From: Roni even To: Andy Pepperell , Roni Even Thread-Topic: [clue] Fwd: #11: RTP header extension for Capture ID Thread-Index: AQHNerpYpnLEF9Ts3kmQmyUlg/lq+JdaEq6A///5yACAAJQTyw== Date: Wed, 15 Aug 2012 09:48:31 +0000 Message-ID: References: <068.5ca029063d5e7080dd9f9169d703adcf@trac.tools.ietf.org> <7F2072F1E0DE894DA4B517B93C6A0585340868365E@ESESSCMS0356.eemea.ericsson.se> <005201cd7a62$40e62260$c2b26720$@gmail.com> <502AB7B1.4070506@alum.mit.edu> <003901cd7ac7$22323a10$6696ae30$@gmail.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.68] Content-Type: multipart/alternative; boundary="_000_EADCEEE0AE4A7F46BD61061696794D9819E89A5Eszxeml536mbx_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "clue@ietf.org" Subject: Re: [clue] Fwd: #11: RTP header extension for Capture ID 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, 15 Aug 2012 09:50:31 -0000 --_000_EADCEEE0AE4A7F46BD61061696794D9819E89A5Eszxeml536mbx_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Andy, Yes the provider should allocate the ID since he is defining the captures a= nd the SSRCs Roni ________________________________ From: clue-bounces@ietf.org [clue-bounces@ietf.org] on behalf of Andy Peppe= rell [apeppere@gmail.com] Sent: Wednesday, August 15, 2012 11:57 To: Roni Even Cc: clue@ietf.org Subject: Re: [clue] Fwd: #11: RTP header extension for Capture ID Hi Roni, I'm not sure I understand the point - are you asking why the consumer is as= signing the IDs rather than the provider? or, taking it further, are you pr= oposing that the provider allocate the IDs? Andy On Wed, Aug 15, 2012 at 10:19 AM, Roni Even > wrote: Andy, I fail to understand why the consumer needs to define the mapping ID for a = mapping done by the provider Roni From: clue-bounces@ietf.org [mailto:clue-boun= ces@ietf.org] On Behalf Of Andy Pepperell Sent: 15 August, 2012 9:48 AM To: christer.holmberg@ericsson.com Cc: clue@ietf.org Subject: Re: [clue] Fwd: #11: RTP header extension for Capture ID Hi Christer, >Is there a reason why we can't use the SSRC? Or, can multiple captures sha= re the same SSRC? I don't think I'm disagreeing here with anything that Roni or Paul are sayi= ng, but was thinking that the phrase "use the SSRC" potentially covers a fe= w different cases... - If we're talking about declaring SSRC values in advance in SDP, this is l= ikely to cause scalability issues with CLUE (more so than with, say, curren= t webrtc implementations) because of the potential for a large number of CL= UE streams in MCU cases. - The current RTP header extension proposal involves the consumer telling t= he provider an ID to use in the RTP header extension for each instantiated = capture, which the consumer can then use to separate the multiple capture i= nstantiations when they are received. It would clearly be reasonably straig= htforward for the CLUE consumer stream choice message to instead indicate a= n SSRC here instead of an ID to be put in an RTP header extension, but as P= aul points out, this means that the consumer then loses the ability to dist= inguish stream changes within a switched capture (modulo CSRC usage). >[Paul] >For instance, for the switched case it would then be necessary to assign a= n ssrc for the switched capture... Agreed, though I think the SSRC assignment would have to be on the basis of= the switched capture's *instantiation* rather than the switched capture it= self - with the simulcast aspects of CLUE as currently defined, mappings ca= n't be on the basis of just capture IDs as a consumer may request multiple = instantiations of the same capture from the provider, and so a simple SSRC = <--> capture ID mapping would not be sufficient. Regards, Andy On Tue, Aug 14, 2012 at 9:40 PM, Paul Kyzivat > wrote: On 8/14/12 5:17 PM, Roni Even wrote: Hi Christer, This works for static SSRCs when the mixer uses its own SSRC. The problem i= s in the switching case when using the source SSRC. An example is when a thre= e camera system has two captures to send to a two monitor system. The three camera system may send first the left and center camera but when switching to center and right camera the center camera will switch from right capture to left capture. This was discussed in my presentation in CLUE about mapping RTP streams. AFAIK it *could* work using SSRC. But then there are different constraints = on how RTP is used. For instance, for the switched case it would then be necessary to assign an= ssrc for the switched capture, and indicate the source via csrc. It also then means that if a source is moved from one switched capture to a= different one, the recipient won't know that it is the *same* RTP stream. = And that affects the number of iframes transmitted, etc. tradeoffs! Thanks, Paul Roni -----Original Message----- From: clue-bounces@ietf.org [mailto:clue-boun= ces@ietf.org] On Behalf Of Christer Holmberg Sent: 14 August, 2012 9:38 PM To: Mary Barnes; CLUE Subject: Re: [clue] Fwd: #11: RTP header extension for Capture ID Hi, A silly question: Is there a reason why we can't use the SSRC? Or, can multiple captures shar= e the same SSRC? Regards, Christer ________________________________ From: clue-bounces@ietf.org [clue-bounces@iet= f.org] On Behalf Of Mary Barnes [mary.ietf.barnes@gmail.com] Sent: Monday, August 13, 2012 10:37 PM To: CLUE Subject: [clue] Fwd: #11: RTP header extension for Capture ID Hi all, I have updated/closed the issues as discussed at the meeting (and captured in the minutes): http://www.ietf.org/proceedings/84/minutes/minutes-84-clu= e I decided to open a ticket to track this issue since it does require some mailing list discussion and hopefully, this will trigger that. The action items from the meeting that are not related to issues are update= s to documents - i.e., new data model document and adding telemedical use cas= e to the WG use case document. Mary. ---------- Forwarded message ---------- From: clue issue tracker >> Date: Mon, Aug 13, 2012 at 2:33 PM Subject: [clue] #11: RTP header extension for Capture ID To: clue-chairs@tools.ietf.org>, mary.ietf.barnes@gmail.com> Cc: clue@ietf.org> #11: RTP header extension for Capture ID Is an RTP header extension needed to transport a capture ID (per draft- lennox-clue-rtp-usage-04)? -- -----------------------------------+--------------------------- Reporter: mary.ietf.barnes@. | Owner:= clue-chairs@. Type: defect | Status: new Priority: major | Milestone: milestone1 Component: charter | Version: 1.0 Severity: Candidate WG Document | Keywords: RTP -----------------------------------+--------------------------- Ticket URL: 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 --_000_EADCEEE0AE4A7F46BD61061696794D9819E89A5Eszxeml536mbx_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Andy,

Yes the provider should allocate the ID since he is defining= the captures and the SSRCs

Roni

From: clue-bounces@ietf.org [clue-bounces@= ietf.org] on behalf of Andy Pepperell [apeppere@gmail.com]
Sent: Wednesday, August 15, 2012 11:57
To: Roni Even
Cc: clue@ietf.org
Subject: Re: [clue] Fwd: #11: RTP header extension for Capture ID
Hi Roni,

I'm not sure I understand the point - are you asking why the consumer = is assigning the IDs rather than the provider? or, taking it further, are y= ou proposing that the provider allocate the IDs?

Andy


On Wed, Aug 15, 2012 at 10:19 AM, Roni Even <ron.even.tl= v@gmail.com> wrote:

Andy,

I fail to understand why the consumer need= s to define the mapping ID for a mapping done by the provider=

Roni

 

From: clue-bounces@iet= f.org [mailto:clue-bounces@ietf.org] On Behalf Of Andy Pepperell
Sent: 15 August, 2012 9:48 AM
To: christer.holmberg@ericsson.com
Cc: clue@ietf.org=


Subject: Re: [clue] Fwd: #11: RTP header extension for Capture ID=

 

Hi Christer,

 

>Is there a reason why we can't use the SSRC? Or,= can multiple captures share the same SSRC?

 

I don't think I'm disagreeing here with anything tha= t Roni or Paul are saying, but was thinking that the phrase "use the S= SRC" potentially covers a few different cases...

 

- If we're talking about declaring SSRC values in ad= vance in SDP, this is likely to cause scalability issues with CLUE (more so= than with, say, current webrtc implementations) because of the potential f= or a large number of CLUE streams in MCU cases.

 

- The current RTP header extension proposal involves= the consumer telling the provider an ID to use in the RTP header extension= for each instantiated capture, which the consumer can then use to separate= the multiple capture instantiations when they are received. It would clearly be reasonably straightforward for= the CLUE consumer stream choice message to instead indicate an SSRC here i= nstead of an ID to be put in an RTP header extension, but as Paul points ou= t, this means that the consumer then loses the ability to distinguish stream changes within a switched cap= ture (modulo CSRC usage).

 

>[Paul]

>For instance, for the switched case it would the= n be necessary to assign an ssrc for the switched capture...<= /p>

 

Agreed, though I think the SSRC assignment would hav= e to be on the basis of the switched capture's *instantiation* rather than = the switched capture itself - with the simulcast aspects of CLUE as cu= rrently defined, mappings can't be on the basis of just capture IDs as a consumer may request multiple instantiation= s of the same capture from the provider, and so a simple SSRC <--> ca= pture ID mapping would not be sufficient.

 

Regards,

 

Andy

 

 

On Tue, Aug 14, 2012 at 9:40 PM, Paul Kyzivat <pkyzivat@alum.mit.= edu> wrote:

On 8/14/12 5:17 PM, Roni Even wrote:

Hi Christer,
This works for static SSRCs when the mixer uses its own SSRC. The problem i= s
in the switching case when using the source SSRC. An example is when a thre= e
camera system has two captures to send to a two monitor system. The three camera system may send first the left and center camera but when switching<= br> to center and right camera the center camera will switch from right capture=
to left capture.
This was discussed in my presentation in CLUE about mapping RTP streams.=

 

AFAIK it *could* work using SSRC. But then there are= different constraints on how RTP is used.

For instance, for the switched case it would then be necessary to assign an= ssrc for the switched capture, and indicate the source via csrc.

It also then means that if a source is moved from one switched capture to a= different one, the recipient won't know that it is the *same* RTP stream. = And that affects the number of iframes transmitted, etc.

tradeoffs!

        Thanks,
        Paul

 

Roni

-----Original Message-----
From: clue-bounc= es@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of
Christer Holmberg
Sent: 14 August, 2012 9:38 PM
To: Mary Barnes; CLUE
Subject: Re: [clue] Fwd: #11: RTP header extension for Capture ID

Hi,

A silly question:

Is there a reason why we can't use the SSRC? Or, can multiple captures shar= e
the same SSRC?

Regards,

Christer

________________________________
From: clue-bounc= es@ietf.org [clue-bounces@ietf.org] On Behalf Of Mary Barnes
[mary.ietf.= barnes@gmail.com]
Sent: Monday, August 13, 2012 10:37 PM
To: CLUE
Subject: [clue] Fwd: #11: RTP header extension for Capture ID

Hi all,

I have updated/closed the issues as discussed at the meeting (and captured<= br> in the minutes):  http://www.ietf.org/proceedings/84/min= utes/minutes-84-clue

I decided to open a ticket to track this issue since it does require some mailing list discussion and hopefully, this will trigger that.

The action items from the meeting that are not related to issues are update= s
to documents - i.e., new data model document and adding telemedical use cas= e
to the WG use case document.

Mary.

---------- Forwarded message ----------
From: clue issue tracker
<tr= ac+clue@trac.tools.ietf.org<mailto:trac%2Bclue@trac.tools.ietf.org>>
Date: Mon, Aug 13, 2012 at 2:33 PM
Subject: [clue] #11: RTP header extension for Capture ID
To: clue-ch= airs@tools.ietf.org<mailto:clue-chairs@tools.ietf.org>,
mary.ietf.b= arnes@gmail.com<mailto:mary.ietf.barnes@gmail.com>
Cc: clue@ietf.org<= ;mailto:clue@ietf.org>


#11: RTP header extension for Capture ID

  Is an RTP header extension needed to transport a capture ID (per dra= ft-
lennox-clue-rtp-usage-04)?

--
-----------------------------------+---------------------------
  Reporter:  mary.ietf.barnes@.     |      Owner:  = clue-chairs@.
      Type:  defect           =       |     Status:  new
  Priority:  major             &nbs= p;    |  Milestone:  milestone1
Component:  charter               &= nbsp;|    Version:  1.0
  Severity:  Candidate WG Document  |   Keywords:  = ;RTP
-----------------------------------+---------------------------

Ticket URL:<http://grenache.tools.ietf.org/wg/clue/trac/ticket/= 11>
clue<http:/= /tools.ietf.org/wg/clue/>


_______________________________________________
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


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

 


--_000_EADCEEE0AE4A7F46BD61061696794D9819E89A5Eszxeml536mbx_-- From apeppere@gmail.com Wed Aug 15 03:34: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 6439821F8768 for ; Wed, 15 Aug 2012 03:34:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.309 X-Spam-Level: X-Spam-Status: No, score=-3.309 tagged_above=-999 required=5 tests=[AWL=0.289, 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 Pkc1wBIFZexk for ; Wed, 15 Aug 2012 03:34: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 99E2F21F875D for ; Wed, 15 Aug 2012 03:34:18 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so1549365vbb.31 for ; Wed, 15 Aug 2012 03:34: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=g0Yas34HXP9Pzm8i3NR2YmiDOliSGGWEZNKpwDzUbfM=; b=o3X4WhfnG5621aX6FR9/hdedU17SGzLEKSP+GZWHgt0TmjMx8lFf4FoZOwFmMWQ7UX g6UueDQ38omiJl4o1kpnLzQStThWz+UpstFfYjj2+He492PA2qxyI63eByGqkFwFggIj s71LPmW5UX9c5GyjbLVkJErBIZEnnMtaNBfeC84sMVUSsgZyP+V9X2vPgqPWMZ9XgMY7 TDC8ELn7y5vbfewbNToMMxHRckuj8wKZE0VpZeIrrgrUbn4Fw+1pgKvBLJJnbTqbYIwg oqdw9O7rt0uW17RI36Q3QEoI1AoAZaYVbaPcSouNiHFo1U1G4FRuvbBUQ1n8y4suM3aR F9wQ== MIME-Version: 1.0 Received: by 10.52.37.137 with SMTP id y9mr830149vdj.100.1345026858034; Wed, 15 Aug 2012 03:34:18 -0700 (PDT) Received: by 10.220.194.134 with HTTP; Wed, 15 Aug 2012 03:34:17 -0700 (PDT) In-Reply-To: References: <068.5ca029063d5e7080dd9f9169d703adcf@trac.tools.ietf.org> <7F2072F1E0DE894DA4B517B93C6A0585340868365E@ESESSCMS0356.eemea.ericsson.se> <005201cd7a62$40e62260$c2b26720$@gmail.com> <502AB7B1.4070506@alum.mit.edu> <003901cd7ac7$22323a10$6696ae30$@gmail.com> Date: Wed, 15 Aug 2012 11:34:17 +0100 Message-ID: From: Andy Pepperell To: Roni even Content-Type: multipart/alternative; boundary=bcaec51dddb91626cc04c74b78ad Cc: "clue@ietf.org" Subject: Re: [clue] Fwd: #11: RTP header extension for Capture ID 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, 15 Aug 2012 10:34:24 -0000 --bcaec51dddb91626cc04c74b78ad Content-Type: text/plain; charset=ISO-8859-1 Hi Roni, The main complexities I'd see with that approach is the simulcast aspect - the provider may have the potential to supply, say, 4 different captures but the consumer could (encoding groups permitting) ask for 4 different encodings of the same capture or 1 encoding of each capture, and the SSRC / header extension ID allocation scheme has to work for all cases. The only way I can see for this to work would be for the provider's advertisement to include a header extension ID or SSRC value associated with each of its encoding groups' constituent potential encodings - that way the consumer would know from its own capture instantiation <--> encoding mapping which ID or SSRC the provider would be using. This has been discussed before and from what I recall (these aren't necessarily my reasons): - it's seen as advantageous for the consumer to allocate the IDs so that it can apply some structure to them (e.g. some sort of hardware routing info) - it's maybe also advantageous to decouple the consumer-side multi-stream demultiplexing from encoding groups' [potential] encodings (if this latter were subject to further / future modifications, for instance in order to cope with some more complex / flexible encoding cases that have been discussed, we wouldn't necessarily want to have to revisit the RTP multi-stream handling). Is this kind of in line with what you were thinking, or did you some other thoughts on where / how the provider would allocate and indicate these? Regards, Andy On Wed, Aug 15, 2012 at 10:48 AM, Roni even wrote: > Hi Andy, > > Yes the provider should allocate the ID since he is defining the captures > and the SSRCs > > Roni > ------------------------------ > *From:* clue-bounces@ietf.org [clue-bounces@ietf.org] on behalf of Andy > Pepperell [apeppere@gmail.com] > *Sent:* Wednesday, August 15, 2012 11:57 > *To:* Roni Even > > *Cc:* clue@ietf.org > *Subject:* Re: [clue] Fwd: #11: RTP header extension for Capture ID > > Hi Roni, > > I'm not sure I understand the point - are you asking why the consumer is > assigning the IDs rather than the provider? or, taking it further, are you > proposing that the provider allocate the IDs? > > Andy > > > On Wed, Aug 15, 2012 at 10:19 AM, Roni Even wrote: > >> Andy,**** >> >> I fail to understand why the consumer needs to define the mapping ID for >> a mapping done by the provider**** >> >> Roni**** >> >> **** >> >> *From:* clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On Behalf >> Of *Andy Pepperell >> *Sent:* 15 August, 2012 9:48 AM >> *To:* christer.holmberg@ericsson.com >> *Cc:* clue@ietf.org >> >> *Subject:* Re: [clue] Fwd: #11: RTP header extension for Capture ID**** >> >> **** >> >> Hi Christer,**** >> >> **** >> >> >Is there a reason why we can't use the SSRC? Or, can multiple captures >> share the same SSRC?**** >> >> **** >> >> I don't think I'm disagreeing here with anything that Roni or Paul are >> saying, but was thinking that the phrase "use the SSRC" potentially covers >> a few different cases...**** >> >> **** >> >> - If we're talking about declaring SSRC values in advance in SDP, this is >> likely to cause scalability issues with CLUE (more so than with, say, >> current webrtc implementations) because of the potential for a large number >> of CLUE streams in MCU cases.**** >> >> **** >> >> - The current RTP header extension proposal involves the consumer telling >> the provider an ID to use in the RTP header extension for each instantiated >> capture, which the consumer can then use to separate the multiple capture >> instantiations when they are received. It would clearly be reasonably >> straightforward for the CLUE consumer stream choice message to instead >> indicate an SSRC here instead of an ID to be put in an RTP header >> extension, but as Paul points out, this means that the consumer then loses >> the ability to distinguish stream changes within a switched capture (modulo >> CSRC usage).**** >> >> **** >> >> >[Paul]**** >> >> >For instance, for the switched case it would then be necessary to assign >> an ssrc for the switched capture...**** >> >> **** >> >> Agreed, though I think the SSRC assignment would have to be on the basis >> of the switched capture's *instantiation* rather than the switched capture >> itself - with the simulcast aspects of CLUE as currently defined, mappings >> can't be on the basis of just capture IDs as a consumer may request >> multiple instantiations of the same capture from the provider, and so a >> simple SSRC <--> capture ID mapping would not be sufficient.**** >> >> **** >> >> Regards,**** >> >> **** >> >> Andy**** >> >> **** >> >> **** >> >> On Tue, Aug 14, 2012 at 9:40 PM, Paul Kyzivat >> wrote:**** >> >> On 8/14/12 5:17 PM, Roni Even wrote:**** >> >> Hi Christer, >> This works for static SSRCs when the mixer uses its own SSRC. The problem >> is >> in the switching case when using the source SSRC. An example is when a >> three >> camera system has two captures to send to a two monitor system. The three >> camera system may send first the left and center camera but when switching >> to center and right camera the center camera will switch from right >> capture >> to left capture. >> This was discussed in my presentation in CLUE about mapping RTP streams.* >> *** >> >> **** >> >> AFAIK it *could* work using SSRC. But then there are different >> constraints on how RTP is used. >> >> For instance, for the switched case it would then be necessary to assign >> an ssrc for the switched capture, and indicate the source via csrc. >> >> It also then means that if a source is moved from one switched capture to >> a different one, the recipient won't know that it is the *same* RTP stream. >> And that affects the number of iframes transmitted, etc. >> >> tradeoffs! >> >> Thanks, >> Paul**** >> >> **** >> >> Roni >> >> -----Original Message----- >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of >> Christer Holmberg >> Sent: 14 August, 2012 9:38 PM >> To: Mary Barnes; CLUE >> Subject: Re: [clue] Fwd: #11: RTP header extension for Capture ID >> >> Hi, >> >> A silly question: >> >> Is there a reason why we can't use the SSRC? Or, can multiple captures >> share >> the same SSRC? >> >> Regards, >> >> Christer >> >> ________________________________ >> From: clue-bounces@ietf.org [clue-bounces@ietf.org] On Behalf Of Mary >> Barnes >> [mary.ietf.barnes@gmail.com] >> Sent: Monday, August 13, 2012 10:37 PM >> To: CLUE >> Subject: [clue] Fwd: #11: RTP header extension for Capture ID >> >> Hi all, >> >> I have updated/closed the issues as discussed at the meeting (and captured >> in the minutes): >> http://www.ietf.org/proceedings/84/minutes/minutes-84-clue >> >> I decided to open a ticket to track this issue since it does require some >> mailing list discussion and hopefully, this will trigger that. >> >> The action items from the meeting that are not related to issues are >> updates >> to documents - i.e., new data model document and adding telemedical use >> case >> to the WG use case document. >> >> Mary. >> >> ---------- Forwarded message ---------- >> From: clue issue tracker >> > >> Date: Mon, Aug 13, 2012 at 2:33 PM >> Subject: [clue] #11: RTP header extension for Capture ID >> To: clue-chairs@tools.ietf.org, >> mary.ietf.barnes@gmail.com >> Cc: clue@ietf.org >> >> >> #11: RTP header extension for Capture ID >> >> Is an RTP header extension needed to transport a capture ID (per draft- >> lennox-clue-rtp-usage-04)? >> >> -- >> -----------------------------------+--------------------------- >> Reporter: mary.ietf.barnes@. | Owner: clue-chairs@. >> Type: defect | Status: new >> Priority: major | Milestone: milestone1 >> Component: charter | Version: 1.0 >> Severity: Candidate WG Document | Keywords: RTP >> -----------------------------------+--------------------------- >> >> Ticket URL: >> 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**** >> >> **** >> > > --bcaec51dddb91626cc04c74b78ad Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Roni,

The main complexities I'd see with th= at approach is the simulcast aspect - the provider may have the potential t= o supply, say, 4 different captures but the consumer could (encoding groups= permitting) ask for 4 different encodings of the same capture or 1 encodin= g of each capture, and the SSRC / header extension ID allocation scheme has= to work for all cases.

The only way I can see for this to work would be for the pro= vider's advertisement to include a header extension ID or SSRC value as= sociated with each of its encoding groups' constituent potential encodi= ngs - that way the consumer would know from its own capture instantiation &= lt;--> encoding mapping which ID or SSRC the provider would be using. Th= is has been discussed before and from what I recall (these aren't neces= sarily my reasons):

- it's seen as advantageous for the consumer to all= ocate the IDs so that it can apply some structure to them (e.g. some sort o= f hardware routing info)

- it's maybe also adv= antageous to decouple the consumer-side multi-stream demultiplexing from en= coding groups' [potential] encodings (if this latter were subject to fu= rther / future modifications, for instance in order to cope with some more = complex / flexible encoding cases that have been discussed, we wouldn't= necessarily want to have to revisit the RTP multi-stream handling).

Is this kind of in line with what you were thinking, or= did you some other thoughts on where / how the provider would allocate and= indicate these?

Regards,

Andy


On Wed, Aug 15, 2012 at 1= 0:48 AM, Roni even <Even.roni@huawei.com> wrote:

Hi Andy,

Yes the provider=A0should allocate the ID since he is defining th= e captures and the SSRCs

Roni

Fro= m: clue-boun= ces@ietf.org [clue-bounces@ietf.org] on behalf of Andy Pepperell [apeppere@gmail.com]
Sent: Wednesday, August 15, 2012 11:57
To: Roni Even

Cc: clue@ietf.org=
Subject: Re: [clue] Fwd: #11: RTP header extension for Capture ID

Hi Roni,

I'm not sure I understand the point - are you asking why the consu= mer is assigning the IDs rather than the provider? or, taking it further, a= re you proposing that the provider allocate the IDs?

Andy


On Wed, Aug 15, 2012 at 10:19 AM, Roni Even <ron.even.tl= v@gmail.com> wrote:

Andy,

I fail to understand why the co= nsumer needs to define the mapping ID for a mapping done by the provider=

Roni

=A0

From: clue-bounces@iet= f.org [mailto:clue-bounces@ietf.org] On Behalf Of Andy Pepperell
Sent: 15 August, 2012 9:48 AM
To: christer.holmberg@ericsson.com
Cc: clue@ietf.org=


Subject: Re: [clue] Fwd: #11: RTP header extension for Capture ID=

=A0

Hi Christer,

=A0

>Is there a reason why we can't use the SSRC?= Or, can multiple captures share=A0the same SSRC?

=A0

I don't think I'm disagreeing here with anyt= hing that Roni or Paul are saying, but was thinking that the phrase "u= se the SSRC" potentially covers a few different cases...=

=A0

- If we're talking about declaring SSRC values i= n advance in SDP, this is likely to cause scalability issues with CLUE (mor= e so than with, say, current webrtc implementations) because of the potenti= al for a large number of CLUE streams in MCU cases.

=A0

- The current RTP header extension proposal involves= the consumer telling the provider an ID to use in the RTP header extension= for each instantiated capture, which the consumer can then use to separate= the multiple capture instantiations when they are received. It would clearly be reasonably straightforward for= the CLUE consumer stream choice message to instead indicate an SSRC here i= nstead of an ID to be put in an RTP header extension, but as Paul points ou= t, this means that the consumer then loses the ability to distinguish stream changes within a switched cap= ture (modulo CSRC usage).

=A0

>[Paul]

>For instance, for the switched case it would the= n be necessary to assign an ssrc for the switched capture...<= /p>

=A0

Agreed, though I think the SSRC assignment would hav= e to be on the basis of the switched capture's *instantiation* rather t= han the switched capture itself - with=A0the simulcast aspects of CLUE as c= urrently defined, mappings can't be on the basis of just capture IDs as a consumer may request multiple instantiation= s of the same capture from the provider, and so a simple SSRC <--> ca= pture ID mapping would not be sufficient.

=A0

Regards,

=A0

Andy

=A0

=A0

On Tue, Aug 14, 2012 at 9:40 PM, Paul Kyzivat <pkyzivat@alum.mit.= edu> wrote:

On 8/14/12 5:17 PM, Roni Even wrote:

Hi Christer,
This works for static SSRCs when the mixer uses its own SSRC. The problem i= s
in the switching case when using the source SSRC. An example is when a thre= e
camera system has two captures to send to a two monitor system. The three camera system may send first the left and center camera but when switching<= br> to center and right camera the center camera will switch from right capture=
to left capture.
This was discussed in my presentation in CLUE about mapping RTP streams.=

=A0

AFAIK it *could* work using SSRC. But then there are= different constraints on how RTP is used.

For instance, for the switched case it would then be necessary to assign an= ssrc for the switched capture, and indicate the source via csrc.

It also then means that if a source is moved from one switched capture to a= different one, the recipient won't know that it is the *same* RTP stre= am. And that affects the number of iframes transmitted, etc.

tradeoffs!

=A0 =A0 =A0 =A0 Thanks,
=A0 =A0 =A0 =A0 Paul

=A0

Roni

-----Original Message-----
From: clue-bounc= es@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of
Christer Holmberg
Sent: 14 August, 2012 9:38 PM
To: Mary Barnes; CLUE
Subject: Re: [clue] Fwd: #11: RTP header extension for Capture ID

Hi,

A silly question:

Is there a reason why we can't use the SSRC? Or, can multiple captures = share
the same SSRC?

Regards,

Christer

________________________________
From: clue-bounc= es@ietf.org [clue-bounces@ietf.org] On Behalf Of Mary Barnes
[mary.ietf.= barnes@gmail.com]
Sent: Monday, August 13, 2012 10:37 PM
To: CLUE
Subject: [clue] Fwd: #11: RTP header extension for Capture ID

Hi all,

I have updated/closed the issues as discussed at the meeting (and captured<= br> in the minutes): =A0http://www.ietf.org/proceedings/84/minute= s/minutes-84-clue

I decided to open a ticket to track this issue since it does require some mailing list discussion and hopefully, this will trigger that.

The action items from the meeting that are not related to issues are update= s
to documents - i.e., new data model document and adding telemedical use cas= e
to the WG use case document.

Mary.

---------- Forwarded message ----------
From: clue issue tracker
<tr= ac+clue@trac.tools.ietf.org<mailto:trac%2Bclue@trac.tools.ietf.org&g= t;>
Date: Mon, Aug 13, 2012 at 2:33 PM
Subject: [clue] #11: RTP header extension for Capture ID
To: clue-ch= airs@tools.ietf.org<mailto:clue-chairs@tools.ietf.org>,
mary.ietf.b= arnes@gmail.com<mailto:mary.ietf.barnes@gmail.com>
Cc: clue@ietf.org<= ;mailto:clue@ietf.org>


#11: RTP header extension for Capture ID

=A0 Is an RTP header extension needed to transport a capture ID (per draft-=
lennox-clue-rtp-usage-04)?

--
-----------------------------------+---------------------------
=A0 Reporter: =A0mar= y.ietf.barnes@. =A0 =A0 | =A0 =A0 =A0Owner: =A0clue-chairs@.
=A0 =A0 =A0 Type: =A0defect =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 Statu= s: =A0new
=A0 Priority: =A0major =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0Milestone: = =A0milestone1
Component: =A0charter =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0Version: =A01= .0
=A0 Severity: =A0Candidate WG Document =A0| =A0 Keywords: =A0RTP
-----------------------------------+---------------------------

Ticket URL:<http://grenache.tools.ietf.org/wg/clue/trac/ticket/= 11>
clue<http:/= /tools.ietf.org/wg/clue/>


_______________________________________________
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


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

=A0



--bcaec51dddb91626cc04c74b78ad-- From ron.even.tlv@gmail.com Wed Aug 15 04:29: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 2177121F86B6 for ; Wed, 15 Aug 2012 04:29:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zeN-h-jIUurP for ; Wed, 15 Aug 2012 04:29:34 -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 152D721F85EF for ; Wed, 15 Aug 2012 04:29:33 -0700 (PDT) Received: by wicr5 with SMTP id r5so3621152wic.13 for ; Wed, 15 Aug 2012 04:29:33 -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:x-mailer:thread-index:content-language; bh=XL6d9Nowo4CWKajwUGh7SjUogpuKnWaRfIugF6TYnCI=; b=l3bT+L37LxZLaCP6jLJJIjo02MeSObXLW7ZvuBtHhP5ZbA1WMp6CEHEeunhKPASzHs Cbu6c731TmtYVSVddJbTmnb8EzJwtfNze/XdkpiiM7k3LAgMaHnCzQOO6cDPd4bzC/bQ ZoFs4uh0rtecrCcWD1/BIdvc7gNfr7JW3ubTQPkQFH4iV/i4CT5C06eGzTQFonKhRGUq NSaNJn6q60L+KCft6JeNtihJCZuYxj4XK30IrM3w/m4+Qk9Qut6pHhL5xryg64uJyMvM 11ObHKZmJIFbDJEgAbkkhAk8LAZHbctqLLp46U6Hjv2dERooG3cMMWbYy7DQJY8QjBsT Qakg== Received: by 10.180.84.1 with SMTP id u1mr36344920wiy.15.1345030173086; Wed, 15 Aug 2012 04:29:33 -0700 (PDT) Received: from RoniE (bzq-79-181-195-163.red.bezeqint.net. [79.181.195.163]) by mx.google.com with ESMTPS id q4sm28074902wix.9.2012.08.15.04.29.29 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 15 Aug 2012 04:29:31 -0700 (PDT) From: "Roni Even" To: "'Andy Pepperell'" , "'Roni even'" References: <068.5ca029063d5e7080dd9f9169d703adcf@trac.tools.ietf.org> <7F2072F1E0DE894DA4B517B93C6A0585340868365E@ESESSCMS0356.eemea.ericsson.se> <005201cd7a62$40e62260$c2b26720$@gmail.com> <502AB7B1.4070506@alum.mit.edu> <003901cd7ac7$22323a10$6696ae30$@gmail.com> In-Reply-To: Date: Wed, 15 Aug 2012 14:28:20 +0200 Message-ID: <005001cd7ae1$76159a90$6240cfb0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0051_01CD7AF2.39A102A0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFM/VlsLWUUBwuvWjT5seMrvYeAmQJvL0GbAjiJEHMBkpDbuQJNqn6UAo7Cq90BwIuCfgHI6I13Ajy/Ug8BBkj53ZfMrkdA Content-Language: en-us Cc: clue@ietf.org Subject: Re: [clue] Fwd: #11: RTP header extension for Capture ID 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, 15 Aug 2012 11:29:36 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0051_01CD7AF2.39A102A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Andy, I think this is an SDP problem. If you can point me to how to describe simulcast in SDP the issue can be solved. If not then we need to solve it for the general case and not only for CLUE Roni From: Andy Pepperell [mailto:apeppere@gmail.com] Sent: 15 August, 2012 12:34 PM To: Roni even Cc: Roni Even; clue@ietf.org Subject: Re: [clue] Fwd: #11: RTP header extension for Capture ID Hi Roni, The main complexities I'd see with that approach is the simulcast aspect - the provider may have the potential to supply, say, 4 different captures but the consumer could (encoding groups permitting) ask for 4 different encodings of the same capture or 1 encoding of each capture, and the SSRC / header extension ID allocation scheme has to work for all cases. The only way I can see for this to work would be for the provider's advertisement to include a header extension ID or SSRC value associated with each of its encoding groups' constituent potential encodings - that way the consumer would know from its own capture instantiation <--> encoding mapping which ID or SSRC the provider would be using. This has been discussed before and from what I recall (these aren't necessarily my reasons): - it's seen as advantageous for the consumer to allocate the IDs so that it can apply some structure to them (e.g. some sort of hardware routing info) - it's maybe also advantageous to decouple the consumer-side multi-stream demultiplexing from encoding groups' [potential] encodings (if this latter were subject to further / future modifications, for instance in order to cope with some more complex / flexible encoding cases that have been discussed, we wouldn't necessarily want to have to revisit the RTP multi-stream handling). Is this kind of in line with what you were thinking, or did you some other thoughts on where / how the provider would allocate and indicate these? Regards, Andy On Wed, Aug 15, 2012 at 10:48 AM, Roni even wrote: Hi Andy, Yes the provider should allocate the ID since he is defining the captures and the SSRCs Roni _____ From: clue-bounces@ietf.org [clue-bounces@ietf.org] on behalf of Andy Pepperell [apeppere@gmail.com] Sent: Wednesday, August 15, 2012 11:57 To: Roni Even Cc: clue@ietf.org Subject: Re: [clue] Fwd: #11: RTP header extension for Capture ID Hi Roni, I'm not sure I understand the point - are you asking why the consumer is assigning the IDs rather than the provider? or, taking it further, are you proposing that the provider allocate the IDs? Andy On Wed, Aug 15, 2012 at 10:19 AM, Roni Even wrote: Andy, I fail to understand why the consumer needs to define the mapping ID for a mapping done by the provider Roni From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Andy Pepperell Sent: 15 August, 2012 9:48 AM To: christer.holmberg@ericsson.com Cc: clue@ietf.org Subject: Re: [clue] Fwd: #11: RTP header extension for Capture ID Hi Christer, >Is there a reason why we can't use the SSRC? Or, can multiple captures share the same SSRC? I don't think I'm disagreeing here with anything that Roni or Paul are saying, but was thinking that the phrase "use the SSRC" potentially covers a few different cases... - If we're talking about declaring SSRC values in advance in SDP, this is likely to cause scalability issues with CLUE (more so than with, say, current webrtc implementations) because of the potential for a large number of CLUE streams in MCU cases. - The current RTP header extension proposal involves the consumer telling the provider an ID to use in the RTP header extension for each instantiated capture, which the consumer can then use to separate the multiple capture instantiations when they are received. It would clearly be reasonably straightforward for the CLUE consumer stream choice message to instead indicate an SSRC here instead of an ID to be put in an RTP header extension, but as Paul points out, this means that the consumer then loses the ability to distinguish stream changes within a switched capture (modulo CSRC usage). >[Paul] >For instance, for the switched case it would then be necessary to assign an ssrc for the switched capture... Agreed, though I think the SSRC assignment would have to be on the basis of the switched capture's *instantiation* rather than the switched capture itself - with the simulcast aspects of CLUE as currently defined, mappings can't be on the basis of just capture IDs as a consumer may request multiple instantiations of the same capture from the provider, and so a simple SSRC <--> capture ID mapping would not be sufficient. Regards, Andy On Tue, Aug 14, 2012 at 9:40 PM, Paul Kyzivat wrote: On 8/14/12 5:17 PM, Roni Even wrote: Hi Christer, This works for static SSRCs when the mixer uses its own SSRC. The problem is in the switching case when using the source SSRC. An example is when a three camera system has two captures to send to a two monitor system. The three camera system may send first the left and center camera but when switching to center and right camera the center camera will switch from right capture to left capture. This was discussed in my presentation in CLUE about mapping RTP streams. AFAIK it *could* work using SSRC. But then there are different constraints on how RTP is used. For instance, for the switched case it would then be necessary to assign an ssrc for the switched capture, and indicate the source via csrc. It also then means that if a source is moved from one switched capture to a different one, the recipient won't know that it is the *same* RTP stream. And that affects the number of iframes transmitted, etc. tradeoffs! Thanks, Paul Roni -----Original Message----- From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Christer Holmberg Sent: 14 August, 2012 9:38 PM To: Mary Barnes; CLUE Subject: Re: [clue] Fwd: #11: RTP header extension for Capture ID Hi, A silly question: Is there a reason why we can't use the SSRC? Or, can multiple captures share the same SSRC? Regards, Christer ________________________________ From: clue-bounces@ietf.org [clue-bounces@ietf.org] On Behalf Of Mary Barnes [mary.ietf.barnes@gmail.com] Sent: Monday, August 13, 2012 10:37 PM To: CLUE Subject: [clue] Fwd: #11: RTP header extension for Capture ID Hi all, I have updated/closed the issues as discussed at the meeting (and captured in the minutes): http://www.ietf.org/proceedings/84/minutes/minutes-84-clue I decided to open a ticket to track this issue since it does require some mailing list discussion and hopefully, this will trigger that. The action items from the meeting that are not related to issues are updates to documents - i.e., new data model document and adding telemedical use case to the WG use case document. Mary. ---------- Forwarded message ---------- From: clue issue tracker >> Date: Mon, Aug 13, 2012 at 2:33 PM Subject: [clue] #11: RTP header extension for Capture ID To: clue-chairs@tools.ietf.org, mary.ietf.barnes@gmail.com Cc: clue@ietf.org #11: RTP header extension for Capture ID Is an RTP header extension needed to transport a capture ID (per draft- lennox-clue-rtp-usage-04)? -- -----------------------------------+--------------------------- Reporter: mary.ietf.barnes@. | Owner: clue-chairs@. Type: defect | Status: new Priority: major | Milestone: milestone1 Component: charter | Version: 1.0 Severity: Candidate WG Document | Keywords: RTP -----------------------------------+--------------------------- Ticket URL: 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 ------=_NextPart_000_0051_01CD7AF2.39A102A0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Andy,

I think this is an SDP problem. If you can point me to how to = describe simulcast in SDP the issue can be solved. If not then we need = to solve it for the general case and not only for = CLUE

Roni

 

From:= = Andy Pepperell [mailto:apeppere@gmail.com]
Sent: 15 August, = 2012 12:34 PM
To: Roni even
Cc: Roni Even; = clue@ietf.org
Subject: Re: [clue] Fwd: #11: RTP header = extension for Capture ID

 

Hi = Roni,

 

The = main complexities I'd see with that approach is the simulcast aspect - = the provider may have the potential to supply, say, 4 different captures = but the consumer could (encoding groups permitting) ask for 4 different = encodings of the same capture or 1 encoding of each capture, and the = SSRC / header extension ID allocation scheme has to work for all = cases.

 

The only way I can see for this to work would be for = the provider's advertisement to include a header extension ID or SSRC = value associated with each of its encoding groups' constituent potential = encodings - that way the consumer would know from its own capture = instantiation <--> encoding mapping which ID or SSRC the provider = would be using. This has been discussed before and from what I recall = (these aren't necessarily my reasons):

 

- = it's seen as advantageous for the consumer to allocate the IDs so that = it can apply some structure to them (e.g. some sort of hardware routing = info)

 

- = it's maybe also advantageous to decouple the consumer-side multi-stream = demultiplexing from encoding groups' [potential] encodings (if this = latter were subject to further / future modifications, for instance in = order to cope with some more complex / flexible encoding cases that have = been discussed, we wouldn't necessarily want to have to revisit the RTP = multi-stream handling).

 

Is this kind of in line with what you were thinking, = or did you some other thoughts on where / how the provider would = allocate and indicate these?

 

Regards,

 

Andy

 

On Wed, Aug 15, 2012 at 10:48 AM, Roni even <Even.roni@huawei.com> = wrote:

Hi = Andy,

Yes the = provider should allocate the ID since he is defining the captures = and the SSRCs

Roni

From:<= span style=3D'font-family:"Tahoma","sans-serif";color:black'> clue-bounces@ietf.org [clue-bounces@ietf.org] on behalf of Andy Pepperell = [apeppere@gmail.com]
Sent: Wednesday, = August 15, 2012 11:57
To: Roni = Even


Cc: = clue@ietf.org
Subject: Re: [clue] Fwd: = #11: RTP header extension for Capture = ID

 

Hi Roni,

 

I'm not sure I understand the point - are you asking = why the consumer is assigning the IDs rather than the provider? or, = taking it further, are you proposing that the provider allocate the = IDs?

 

Andy

 

On Wed, Aug 15, 2012 at 10:19 AM, Roni Even <ron.even.tlv@gmail.com> = wrote:

Andy,

I fail to understand why the consumer needs to define the mapping ID = for a mapping done by the provider

Roni

 <= /o:p>

From:= = clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Andy = Pepperell
Sent: 15 August, 2012 9:48 AM
To: christer.holmberg@ericsson.com
Cc: clue@ietf.org


Subject: Re: [clue] Fwd: #11: RTP header = extension for Capture ID

 <= /o:p>

Hi = Christer,

 <= /o:p>

>Is = there a reason why we can't use the SSRC? Or, can multiple captures = share the same SSRC?

 <= /o:p>

I don't = think I'm disagreeing here with anything that Roni or Paul are saying, = but was thinking that the phrase "use the SSRC" potentially = covers a few different cases...

 <= /o:p>

- If we're = talking about declaring SSRC values in advance in SDP, this is likely to = cause scalability issues with CLUE (more so than with, say, current = webrtc implementations) because of the potential for a large number of = CLUE streams in MCU cases.

 <= /o:p>

- The = current RTP header extension proposal involves the consumer telling the = provider an ID to use in the RTP header extension for each instantiated = capture, which the consumer can then use to separate the multiple = capture instantiations when they are received. It would clearly be = reasonably straightforward for the CLUE consumer stream choice message = to instead indicate an SSRC here instead of an ID to be put in an RTP = header extension, but as Paul points out, this means that the consumer = then loses the ability to distinguish stream changes within a switched = capture (modulo CSRC usage).

 <= /o:p>

>[Paul]

>For = instance, for the switched case it would then be necessary to assign an = ssrc for the switched capture...

 <= /o:p>

Agreed, = though I think the SSRC assignment would have to be on the basis of the = switched capture's *instantiation* rather than the switched capture = itself - with the simulcast aspects of CLUE as currently defined, = mappings can't be on the basis of just capture IDs as a consumer may = request multiple instantiations of the same capture from the provider, = and so a simple SSRC <--> capture ID mapping would not be = sufficient.

 <= /o:p>

Regards,

 <= /o:p>

Andy

 <= /o:p>

 <= /o:p>

On Tue, Aug = 14, 2012 at 9:40 PM, Paul Kyzivat <pkyzivat@alum.mit.edu> = wrote:

On 8/14/12 = 5:17 PM, Roni Even wrote:

Hi = Christer,
This works for static SSRCs when the mixer uses its own = SSRC. The problem is
in the switching case when using the source = SSRC. An example is when a three
camera system has two captures to = send to a two monitor system. The three
camera system may send first = the left and center camera but when switching
to center and right = camera the center camera will switch from right capture
to left = capture.
This was discussed in my presentation in CLUE about mapping = RTP streams.

 <= /o:p>

AFAIK it = *could* work using SSRC. But then there are different constraints on how = RTP is used.

For instance, for the switched case it would then be = necessary to assign an ssrc for the switched capture, and indicate the = source via csrc.

It also then means that if a source is moved = from one switched capture to a different one, the recipient won't know = that it is the *same* RTP stream. And that affects the number of iframes = transmitted, etc.

tradeoffs!

        = Thanks,
        = Paul

 <= /p>

Roni

-----O= riginal Message-----
From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of
Christer = Holmberg
Sent: 14 August, 2012 9:38 PM
To: Mary Barnes; = CLUE
Subject: Re: [clue] Fwd: #11: RTP header extension for Capture = ID

Hi,

A silly question:

Is there a reason why we = can't use the SSRC? Or, can multiple captures share
the same = SSRC?

Regards,

Christer

____________________________= ____
From: clue-bounces@ietf.org [clue-bounces@ietf.org] On Behalf Of Mary = Barnes
[mary.ietf.barnes@gmail.com]
Sent: Monday, = August 13, 2012 10:37 PM
To: CLUE
Subject: [clue] Fwd: #11: RTP = header extension for Capture ID

Hi all,

I have = updated/closed the issues as discussed at the meeting (and = captured
in the minutes):  http://www.ietf.org/proceedings/84/minutes/minutes-84-c= lue

I decided to open a ticket to track this issue since it = does require some
mailing list discussion and hopefully, this will = trigger that.

The action items from the meeting that are not = related to issues are updates
to documents - i.e., new data model = document and adding telemedical use case
to the WG use case = document.

Mary.

---------- Forwarded message = ----------
From: clue issue tracker
<trac+clue@trac.tools.ietf.org<mailto:trac%2Bclue@trac.tools.ietf.org>>
Date: = Mon, Aug 13, 2012 at 2:33 PM
Subject: [clue] #11: RTP header = extension for Capture ID
To: clue-chairs@tools.ietf.org<mailto:clue-chairs@tools.ietf.org>,
mary.ietf.barnes@gmail.com<mailto:mary.ietf.barnes@gmail.com>
Cc: clue@ietf.org<mailto:clue@ietf.org>


#11: RTP header = extension for Capture ID

  Is an RTP header extension needed = to transport a capture ID (per = draft-
lennox-clue-rtp-usage-04)?

--
-----------------------= ------------+---------------------------
  Reporter:  mary.ietf.barnes@.     |     =  Owner:  clue-chairs@.
      Type: =  defect                 | =     Status:  new
  Priority:  major   =                | =  Milestone:  milestone1
Component:  charter   =              |    Version: =  1.0
  Severity:  Candidate WG Document  |   = Keywords: =  RTP
-----------------------------------+------------------------= ---

Ticket URL:<http://grenache.tools.ietf.org/wg/clue/trac/ticket/11>
clue<http://tools.ietf.org/wg/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

 <= /o:p>

 

 

------=_NextPart_000_0051_01CD7AF2.39A102A0-- From apeppere@gmail.com Wed Aug 15 08:14: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 8F3D221E80EA for ; Wed, 15 Aug 2012 08:14:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.338 X-Spam-Level: X-Spam-Status: No, score=-3.338 tagged_above=-999 required=5 tests=[AWL=0.260, 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 QEx5Rrd4TOQf for ; Wed, 15 Aug 2012 08:14:53 -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 8F0D621E80D0 for ; Wed, 15 Aug 2012 08:14:50 -0700 (PDT) Received: by bkty7 with SMTP id y7so679597bkt.31 for ; Wed, 15 Aug 2012 08:14:49 -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=sQyHshMat2XKJhtxfzyC1E1uNVtjYthfXyfXHwrUbsY=; b=lldB4+WKI8aG7keqwSLyRoYtNMQCzEpAKdooEhp+o6OwOfdStphkdGNLFyH02Sh7FE MQ1Vci7uq8P/9jIOM9ZVgRJIpSebv9wDN1aT+sMjz0twB4+EIOmZIi7xKKYi7xoxHx3l +LcDsoFJRMRx4J3XlJnTHWzLeuS9jI35Zdx+q8zwtx45oTKx6kXbG0WEfyYcjhIWAV7S pyN9Wef4ODRAgrEJ4ofeCG2N/LSDMnSFHLNKLLfZ9cgYnTRsadLfOnhCKU+h/h3I2JM/ x1b+SAEZVB46jVwaKlv7PIdar7x+iCFCgNTa3XiVB7Sct+JqTJHqql+XXTMuxS6+Cl2Q 0rjg== MIME-Version: 1.0 Received: by 10.205.127.131 with SMTP id ha3mr8094927bkc.123.1345043689446; Wed, 15 Aug 2012 08:14:49 -0700 (PDT) Received: by 10.204.7.150 with HTTP; Wed, 15 Aug 2012 08:14:49 -0700 (PDT) In-Reply-To: <005001cd7ae1$76159a90$6240cfb0$@gmail.com> References: <068.5ca029063d5e7080dd9f9169d703adcf@trac.tools.ietf.org> <7F2072F1E0DE894DA4B517B93C6A0585340868365E@ESESSCMS0356.eemea.ericsson.se> <005201cd7a62$40e62260$c2b26720$@gmail.com> <502AB7B1.4070506@alum.mit.edu> <003901cd7ac7$22323a10$6696ae30$@gmail.com> <005001cd7ae1$76159a90$6240cfb0$@gmail.com> Date: Wed, 15 Aug 2012 16:14:49 +0100 Message-ID: From: Andy Pepperell To: Roni Even Content-Type: multipart/alternative; boundary=0015173fe4ac511d6a04c74f6350 Cc: clue@ietf.org Subject: Re: [clue] Fwd: #11: RTP header extension for Capture ID 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, 15 Aug 2012 15:14:54 -0000 --0015173fe4ac511d6a04c74f6350 Content-Type: text/plain; charset=ISO-8859-1 Hi Roni, I'm not sure of the validity of needing simulcast defined in SDP before we can start to think about it in CLUE. The messages and mechanisms as currently defined in CLUE give us simulcast functionality without the need for SDP additions (which wouldn't necessarily be a good fit for CLUE anyway, just like the pre-declaration of SSRC values doesn't scale all that well to all CLUE multi-stream use cases). >If you can point me to how to describe simulcast in SDP the issue can be solved. As above, I don't believe this is a prerequisite at all for us to be able to make progress in CLUE. Or, alternatively, introducing dependencies on such general solutions which may or may not be in the pipeline would seem likely only to impede progress on CLUE (IMHO, of course!). Regards, Andy On Wed, Aug 15, 2012 at 1:28 PM, Roni Even wrote: > Hi Andy,**** > > I think this is an SDP problem. If you can point me to how to describe > simulcast in SDP the issue can be solved. If not then we need to solve it > for the general case and not only for CLUE**** > > Roni**** > > ** ** > > *From:* Andy Pepperell [mailto:apeppere@gmail.com] > *Sent:* 15 August, 2012 12:34 PM > *To:* Roni even > *Cc:* Roni Even; clue@ietf.org > > *Subject:* Re: [clue] Fwd: #11: RTP header extension for Capture ID**** > > ** ** > > Hi Roni,**** > > ** ** > > The main complexities I'd see with that approach is the simulcast aspect - > the provider may have the potential to supply, say, 4 different captures > but the consumer could (encoding groups permitting) ask for 4 different > encodings of the same capture or 1 encoding of each capture, and the SSRC / > header extension ID allocation scheme has to work for all cases.**** > > ** ** > > The only way I can see for this to work would be for the provider's > advertisement to include a header extension ID or SSRC value associated > with each of its encoding groups' constituent potential encodings - that > way the consumer would know from its own capture instantiation <--> > encoding mapping which ID or SSRC the provider would be using. This has > been discussed before and from what I recall (these aren't necessarily my > reasons):**** > > ** ** > > - it's seen as advantageous for the consumer to allocate the IDs so that > it can apply some structure to them (e.g. some sort of hardware routing > info)**** > > ** ** > > - it's maybe also advantageous to decouple the consumer-side multi-stream > demultiplexing from encoding groups' [potential] encodings (if this latter > were subject to further / future modifications, for instance in order to > cope with some more complex / flexible encoding cases that have been > discussed, we wouldn't necessarily want to have to revisit the RTP > multi-stream handling).**** > > ** ** > > Is this kind of in line with what you were thinking, or did you some other > thoughts on where / how the provider would allocate and indicate these?*** > * > > ** ** > > Regards,**** > > ** ** > > Andy**** > > ** ** > > On Wed, Aug 15, 2012 at 10:48 AM, Roni even wrote:* > *** > > Hi Andy,**** > > Yes the provider should allocate the ID since he is defining the captures > and the SSRCs**** > > Roni**** > ------------------------------ > > *From:* clue-bounces@ietf.org [clue-bounces@ietf.org] on behalf of Andy > Pepperell [apeppere@gmail.com] > *Sent:* Wednesday, August 15, 2012 11:57 > *To:* Roni Even**** > > > *Cc:* clue@ietf.org > *Subject:* Re: [clue] Fwd: #11: RTP header extension for Capture ID**** > > ** ** > > Hi Roni, **** > > ** ** > > I'm not sure I understand the point - are you asking why the consumer is > assigning the IDs rather than the provider? or, taking it further, are you > proposing that the provider allocate the IDs?**** > > ** ** > > Andy**** > > ** ** > > On Wed, Aug 15, 2012 at 10:19 AM, Roni Even > wrote:**** > > Andy,**** > > I fail to understand why the consumer needs to define the mapping ID for a > mapping done by the provider**** > > Roni**** > > **** > > *From:* clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On Behalf > Of *Andy Pepperell > *Sent:* 15 August, 2012 9:48 AM > *To:* christer.holmberg@ericsson.com > *Cc:* clue@ietf.org**** > > > *Subject:* Re: [clue] Fwd: #11: RTP header extension for Capture ID**** > > **** > > Hi Christer,**** > > **** > > >Is there a reason why we can't use the SSRC? Or, can multiple captures > share the same SSRC?**** > > **** > > I don't think I'm disagreeing here with anything that Roni or Paul are > saying, but was thinking that the phrase "use the SSRC" potentially covers > a few different cases...**** > > **** > > - If we're talking about declaring SSRC values in advance in SDP, this is > likely to cause scalability issues with CLUE (more so than with, say, > current webrtc implementations) because of the potential for a large number > of CLUE streams in MCU cases.**** > > **** > > - The current RTP header extension proposal involves the consumer telling > the provider an ID to use in the RTP header extension for each instantiated > capture, which the consumer can then use to separate the multiple capture > instantiations when they are received. It would clearly be reasonably > straightforward for the CLUE consumer stream choice message to instead > indicate an SSRC here instead of an ID to be put in an RTP header > extension, but as Paul points out, this means that the consumer then loses > the ability to distinguish stream changes within a switched capture (modulo > CSRC usage).**** > > **** > > >[Paul]**** > > >For instance, for the switched case it would then be necessary to assign > an ssrc for the switched capture...**** > > **** > > Agreed, though I think the SSRC assignment would have to be on the basis > of the switched capture's *instantiation* rather than the switched capture > itself - with the simulcast aspects of CLUE as currently defined, mappings > can't be on the basis of just capture IDs as a consumer may request > multiple instantiations of the same capture from the provider, and so a > simple SSRC <--> capture ID mapping would not be sufficient.**** > > **** > > Regards,**** > > **** > > Andy**** > > **** > > **** > > On Tue, Aug 14, 2012 at 9:40 PM, Paul Kyzivat > wrote:**** > > On 8/14/12 5:17 PM, Roni Even wrote:**** > > Hi Christer, > This works for static SSRCs when the mixer uses its own SSRC. The problem > is > in the switching case when using the source SSRC. An example is when a > three > camera system has two captures to send to a two monitor system. The three > camera system may send first the left and center camera but when switching > to center and right camera the center camera will switch from right capture > to left capture. > This was discussed in my presentation in CLUE about mapping RTP streams.** > ** > > **** > > AFAIK it *could* work using SSRC. But then there are different constraints > on how RTP is used. > > For instance, for the switched case it would then be necessary to assign > an ssrc for the switched capture, and indicate the source via csrc. > > It also then means that if a source is moved from one switched capture to > a different one, the recipient won't know that it is the *same* RTP stream. > And that affects the number of iframes transmitted, etc. > > tradeoffs! > > Thanks, > Paul**** > > **** > > Roni > > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Christer Holmberg > Sent: 14 August, 2012 9:38 PM > To: Mary Barnes; CLUE > Subject: Re: [clue] Fwd: #11: RTP header extension for Capture ID > > Hi, > > A silly question: > > Is there a reason why we can't use the SSRC? Or, can multiple captures > share > the same SSRC? > > Regards, > > Christer > > ________________________________ > From: clue-bounces@ietf.org [clue-bounces@ietf.org] On Behalf Of Mary > Barnes > [mary.ietf.barnes@gmail.com] > Sent: Monday, August 13, 2012 10:37 PM > To: CLUE > Subject: [clue] Fwd: #11: RTP header extension for Capture ID > > Hi all, > > I have updated/closed the issues as discussed at the meeting (and captured > in the minutes): > http://www.ietf.org/proceedings/84/minutes/minutes-84-clue > > I decided to open a ticket to track this issue since it does require some > mailing list discussion and hopefully, this will trigger that. > > The action items from the meeting that are not related to issues are > updates > to documents - i.e., new data model document and adding telemedical use > case > to the WG use case document. > > Mary. > > ---------- Forwarded message ---------- > From: clue issue tracker > > > Date: Mon, Aug 13, 2012 at 2:33 PM > Subject: [clue] #11: RTP header extension for Capture ID > To: clue-chairs@tools.ietf.org, > mary.ietf.barnes@gmail.com > Cc: clue@ietf.org > > > #11: RTP header extension for Capture ID > > Is an RTP header extension needed to transport a capture ID (per draft- > lennox-clue-rtp-usage-04)? > > -- > -----------------------------------+--------------------------- > Reporter: mary.ietf.barnes@. | Owner: clue-chairs@. > Type: defect | Status: new > Priority: major | Milestone: milestone1 > Component: charter | Version: 1.0 > Severity: Candidate WG Document | Keywords: RTP > -----------------------------------+--------------------------- > > Ticket URL: > 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**** > > **** > > ** ** > > ** ** > --0015173fe4ac511d6a04c74f6350 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Roni,

I'm not sure of the validity of needing sim= ulcast defined in SDP before we can start to think about it in CLUE. The me= ssages and mechanisms as currently defined in CLUE give us simulcast functi= onality without the need for SDP additions (which wouldn't necessarily = be a good fit for CLUE anyway, just like the pre-declaration of SSRC values= doesn't scale all that well to all CLUE multi-stream use cases).

>If you can point me to how to describe simulcast in= SDP the issue can be solved.

As above, I don'= t believe this is a prerequisite at all for us to be able to make progress = in CLUE. Or, alternatively, introducing dependencies on such general soluti= ons which may or may not be in the pipeline would seem likely only to imped= e progress on CLUE (IMHO, of course!).

Regards,

Andy

On Wed, Aug 15, 2012 at 1:28 PM, Roni Even <ron.even.tlv@gmail.com> wrote:

Hi Andy,

I think this is an SDP pr= oblem. If you can point me to how to describe simulcast in SDP the issue ca= n be solved. If not then we need to solve it for the general case and not o= nly for CLUE

Roni=

=A0

From: Andy Pep= perell [mailto:apep= pere@gmail.com]
Sent: 15 August, 2012 12:34 PM
To: Roni even
Cc:= Roni Even; clue@ietf.or= g


Subject: Re: [clue] Fwd: = #11: RTP header extension for Capture ID

=A0

Hi Roni,

=A0

The mai= n complexities I'd see with that approach is the simulcast aspect - the= provider may have the potential to supply, say, 4 different captures but t= he consumer could (encoding groups permitting) ask for 4 different encoding= s of the same capture or 1 encoding of each capture, and the SSRC / header = extension ID allocation scheme has to work for all cases.

=A0

The only way I can see for this to work would be for the provider&#= 39;s advertisement to include a header extension ID or SSRC value associate= d with each of its encoding groups' constituent potential encodings - t= hat way the consumer would know from its own capture instantiation <--&g= t; encoding mapping which ID or SSRC the provider would be using. This has = been discussed before and from what I recall (these aren't necessarily = my reasons):

=A0

- it's seen as advantageous for the consumer to allocate= the IDs so that it can apply some structure to them (e.g. some sort of har= dware routing info)

=A0

- it's maybe also advantageous to decouple the consumer-= side multi-stream demultiplexing from encoding groups' [potential] enco= dings (if this latter were subject to further / future modifications, for i= nstance in order to cope with some more complex / flexible encoding cases t= hat have been discussed, we wouldn't necessarily want to have to revisi= t the RTP multi-stream handling).

=A0

Is this kind of in line with what you were thinking, or did = you some other thoughts on where / how the provider would allocate and indi= cate these?

=A0

Regards,

=A0

Andy

=A0

On Wed, Aug 15, 2012 at 10= :48 AM, Roni even <Even.roni@huawei.com> wrote:

Hi Andy,

Yes the provider=A0should allocate the ID since he is defini= ng the captures and the SSRCs

Roni

=

From: = clue-bounces@ietf.org [clue-bounces@ietf.org] on behalf of Andy Pepperell [apeppere@gmail.com] Sent: Wednesday, August 15, 2012 11:57
To: Roni Even


Cc: clue@ietf.org
Subject: Re: [clue] Fwd: #11: RTP header extension for Capture ID=

=A0<= /p>

Hi Roni,

<= div>

=A0

I'm not sure I understand the point - are you asking why the consume= r is assigning the IDs rather than the provider? or, taking it further, are= you proposing that the provider allocate the IDs?

=A0

Andy

=A0

On Wed, Aug 15, 2012 at 10:19 AM, Roni Even <ron.even.tlv@gmail.com> wrote:<= /u>

Andy,=

I fail to = understand why the consumer needs to define the mapping ID for a mapping do= ne by the provider

Roni=

=A0

<= span style=3D"font-size:10.0pt;font-family:"Tahoma","sans-se= rif"">From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On = Behalf Of Andy Pepperell
Sent: 15 August, 2012 9:48 AM
To: christer.holmberg@ericsson.com<= /a>
Cc: clue@i= etf.org


Subject: Re: [clue] Fwd: #11: R= TP header extension for Capture ID

<= p class=3D"MsoNormal">=A0

Hi Christ= er,

=A0

>Is there a reason why we can't use the SSRC? Or, can= multiple captures share=A0the same SSRC?

=A0

I don't think I&= #39;m disagreeing here with anything that Roni or Paul are saying, but was = thinking that the phrase "use the SSRC" potentially covers a few = different cases...

=A0

- If we're talking about declaring SSRC values in advanc= e in SDP, this is likely to cause scalability issues with CLUE (more so tha= n with, say, current webrtc implementations) because of the potential for a= large number of CLUE streams in MCU cases.

=A0

- The current RTP header extension proposal involves the con= sumer telling the provider an ID to use in the RTP header extension for eac= h instantiated capture, which the consumer can then use to separate the mul= tiple capture instantiations when they are received. It would clearly be re= asonably straightforward for the CLUE consumer stream choice message to ins= tead indicate an SSRC here instead of an ID to be put in an RTP header exte= nsion, but as Paul points out, this means that the consumer then loses the = ability to distinguish stream changes within a switched capture (modulo CSR= C usage).

=A0

>[Paul]

>For instance, for the switched case it would then be necessary to ass= ign an ssrc for the switched capture...

=A0

Agreed, though I think the SSRC assignment would have to be = on the basis of the switched capture's *instantiation* rather than the = switched capture itself - with=A0the simulcast aspects of CLUE as currently= defined, mappings can't be on the basis of just capture IDs as a consu= mer may request multiple instantiations of the same capture from the provid= er, and so a simple SSRC <--> capture ID mapping would not be suffici= ent.

=A0

Regards,

= =A0

Andy

=A0

= =A0

On Tue, Aug 14, 2012 at 9:= 40 PM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:

On 8/14/12 5:17 PM, Roni Even wrote:<= /u>

Hi Christer,
This works for static SSRCs w= hen the mixer uses its own SSRC. The problem is
in the switching case wh= en using the source SSRC. An example is when a three
camera system has two captures to send to a two monitor system. The threecamera system may send first the left and center camera but when switchin= g
to center and right camera the center camera will switch from right ca= pture
to left capture.
This was discussed in my presentation in CLUE about map= ping RTP streams.

=A0=

AFAIK it *could* work using SSRC. But then= there are different constraints on how RTP is used.

For instance, for the switched case it would then be necessary to assig= n an ssrc for the switched capture, and indicate the source via csrc.
It also then means that if a source is moved from one switched capture to= a different one, the recipient won't know that it is the *same* RTP st= ream. And that affects the number of iframes transmitted, etc.

tradeoffs!

=A0 =A0 =A0 =A0 Thanks,
=A0 =A0 =A0 =A0 Paul

=A0

=

Roni

-----Orig= inal Message-----
From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of
Christer Holmberg
Sent: 14 August, 2012 9:38 PM
To: Mary Barnes; CLUE=
Subject: Re: [clue] Fwd: #11: RTP header extension for Capture ID
Hi,

A silly question:

Is there a reason why we can't us= e the SSRC? Or, can multiple captures share
the same SSRC?

Regards,

Christer

_____________________= ___________
From: clue-bounces@ietf.org [clue-bounces@ietf.org] On Behalf Of Mary Barnes
[mary.ietf.= barnes@gmail.com]
Sent: Monday, August 13, 2012 10:37 PM
To: CLUE=
Subject: [clue] Fwd: #11: RTP header extension for Capture ID

Hi= all,

I have updated/closed the issues as discussed at the meeting (and captu= red
in the minutes): =A0http://www.ietf.org/proceedings/84= /minutes/minutes-84-clue

I decided to open a ticket to track this issue since it does require so= me
mailing list discussion and hopefully, this will trigger that.
The action items from the meeting that are not related to issues are updat= es
to documents - i.e., new data model document and adding telemedical use cas= e
to the WG use case document.

Mary.

---------- Forwarded = message ----------
From: clue issue tracker
<trac+clue@trac.tools.ietf.o= rg<mailto:trac%2Bclue@trac.tools.ietf.org>>
Date: Mon, Aug 13, 2012 at 2:33 PM
Subject: [clue] #11: RTP header exten= sion for Capture ID
To: clue-chairs@tools.ietf.org<mailto:clue-chairs@tools.ietf.org>,
mary.ietf.b= arnes@gmail.com<mailto:mary.ietf.barnes@gmail.com>
Cc: clue@ietf.org<mailto:clue@ietf.org>


#11: RTP header extension for Capture ID

=A0 Is an RTP heade= r extension needed to transport a capture ID (per draft-
lennox-clue-rtp= -usage-04)?

--
-----------------------------------+--------------= -------------
=A0 Reporter: =A0mar= y.ietf.barnes@. =A0 =A0 | =A0 =A0 =A0Owner: =A0clue-chairs@.
=A0 =A0= =A0 Type: =A0defect =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 Status: =A0n= ew
=A0 Priority: =A0major =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0Milest= one: =A0milestone1
Component: =A0charter =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0Version: =A01= .0
=A0 Severity: =A0Candidate WG Document =A0| =A0 Keywords: =A0RTP
-= ----------------------------------+---------------------------

Ticke= t URL:<http://grenache.tools.ietf.org/wg/clue/trac/ticket/11>
clue<http:/= /tools.ietf.org/wg/clue/>


_______________________________= ________________
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

=


_______________________________________________<= br> clue mailing list
clu= e@ietf.org
https://www.ietf.org/mailman/listinfo/clue

=A0

<= /div>

=A0

=A0


--0015173fe4ac511d6a04c74f6350-- From pkyzivat@alum.mit.edu Wed Aug 15 08:41: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 1822D21F87F3 for ; Wed, 15 Aug 2012 08:41:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.286 X-Spam-Level: X-Spam-Status: No, score=-2.286 tagged_above=-999 required=5 tests=[AWL=0.313, 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 jYjyYuAZqokj for ; Wed, 15 Aug 2012 08:41:48 -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 E92EF21F85A5 for ; Wed, 15 Aug 2012 08:41:35 -0700 (PDT) Received: from omta07.westchester.pa.mail.comcast.net ([76.96.62.59]) by qmta09.westchester.pa.mail.comcast.net with comcast id mz5R1j0021GhbT8593heTb; Wed, 15 Aug 2012 15:41:38 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta07.westchester.pa.mail.comcast.net with comcast id n3hr1j0043ZTu2S3T3hraL; Wed, 15 Aug 2012 15:41:51 +0000 Message-ID: <502BC32E.6010205@alum.mit.edu> Date: Wed, 15 Aug 2012 11:41: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: <068.5ca029063d5e7080dd9f9169d703adcf@trac.tools.ietf.org> <7F2072F1E0DE894DA4B517B93C6A0585340868365E@ESESSCMS0356.eemea.ericsson.se> <005201cd7a62$40e62260$c2b26720$@gmail.com> <502AB7B1.4070506@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] Fwd: #11: RTP header extension for Capture ID 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, 15 Aug 2012 15:41:49 -0000 [as an individual] Note: I'm not advocating for either position here - I'm just trying to explore the implications of one vs. the other. On 8/15/12 3:48 AM, Andy Pepperell wrote: > Hi Christer, > > >Is there a reason why we can't use the SSRC? Or, can multiple captures > share the same SSRC? > > I don't think I'm disagreeing here with anything that Roni or Paul are > saying, but was thinking that the phrase "use the SSRC" potentially > covers a few different cases... > > - If we're talking about declaring SSRC values in advance in SDP, this > is likely to cause scalability issues with CLUE (more so than with, say, > current webrtc implementations) because of the potential for a large > number of CLUE streams in MCU cases. AFAIK the question here is about whether we need an RTP extension to carry the capture ID in RTP. And the purpose of this is to correlate it with a capture ID carried in the CLUE signaling. I *think* the suggestion to use the SSRC just means using it as the capture ID - associating an SSRC with each capture in CLUE signaling. Then, since the SSRC is already in the RTP, there is no need for an extension to carry capture ID. I don't think there is any *requirement* to carry SSRCs in SDP. > - The current RTP header extension proposal involves the consumer > telling the provider an ID to use in the RTP header extension for each > instantiated capture, which the consumer can then use to separate the > multiple capture instantiations when they are received. It would clearly > be reasonably straightforward for the CLUE consumer stream choice > message to instead indicate an SSRC here instead of an ID yep > to be put in an RTP header extension, but you don't need to put it in an extension. Its already in every RTP message. > but as Paul points out, this means that the > consumer then loses the ability to distinguish stream changes within a > switched capture (modulo CSRC usage). Well, clearly you *can* distinguish stream changes by noting that the CSRCs have changed. But what you can't do is determine that a particular source stream has moved from one switched capture to another. (You can note that the switched capture associated with SSRC A used to have a single CSRC - C. And now switched capture with SSRC B has the single CSRC C. But its still a leap of faith to assume that means those messages can be treated as a single RTP stream. > >[Paul] > >For instance, for the switched case it would then be necessary to > assign an ssrc for the switched capture... > > Agreed, though I think the SSRC assignment would have to be on the basis > of the switched capture's *instantiation* rather than the switched > capture itself - with the simulcast aspects of CLUE as currently > defined, mappings can't be on the basis of just capture IDs as a > consumer may request multiple instantiations of the same capture from > the provider, and so a simple SSRC <--> capture ID mapping would not be > sufficient. Yes, you are right about that. Thanks, Paul From ron.even.tlv@gmail.com Wed Aug 15 09:18: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 D347B21E80F5 for ; Wed, 15 Aug 2012 09:18:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.496 X-Spam-Level: X-Spam-Status: No, score=-3.496 tagged_above=-999 required=5 tests=[AWL=0.102, 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 6+V8erw6t49D for ; Wed, 15 Aug 2012 09:18:08 -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 8341521E80F2 for ; Wed, 15 Aug 2012 09:18:05 -0700 (PDT) Received: by weyu54 with SMTP id u54so1291765wey.31 for ; Wed, 15 Aug 2012 09:18:04 -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:x-mailer:thread-index:content-language; bh=4XJ8smFcZpKFQO2JRETpd0GU1CG46G1Wih4u++MDS4M=; b=yGJj8zaEH6pi4NQRZCtwTFW5FDNJVqLnjfSajfoE31tigc+XUNG4PAxSILJcVuzpB9 ODQsARSgQFAIpOAgQEFOSWlAx/yy6dWI6j0iU7DORb65lKzDsvux8jiGL1QdC938WDYO wqYhDRTW7AXrahqgj3DxbW+1HepBFQfatkxGh5d70HTS23LoFHQ1GC10Mkems/FrrgmD B8tL6IBf+nAUl3m2wjkMn1wMwIAFMZcCiIn6gwzoMc2dRAOa1yr3OV8djqCxTSb6J37y kgJwxQalVEdYoCJTVbT0jOO15d0XL5LMznJG6htf24/Z2veu5ME8+jKAzmh2oiMVjLKw iyDA== Received: by 10.180.19.169 with SMTP id g9mr38084274wie.9.1345047484587; Wed, 15 Aug 2012 09:18:04 -0700 (PDT) Received: from RoniE (bzq-79-176-230-98.red.bezeqint.net. [79.176.230.98]) by mx.google.com with ESMTPS id el6sm29482312wib.8.2012.08.15.09.18.00 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 15 Aug 2012 09:18:03 -0700 (PDT) From: "Roni Even" To: "'Andy Pepperell'" References: <068.5ca029063d5e7080dd9f9169d703adcf@trac.tools.ietf.org> <7F2072F1E0DE894DA4B517B93C6A0585340868365E@ESESSCMS0356.eemea.ericsson.se> <005201cd7a62$40e62260$c2b26720$@gmail.com> <502AB7B1.4070506@alum.mit.edu> <003901cd7ac7$22323a10$6696ae30$@gmail.com> <005001cd7ae1$76159a90$6240cfb0$@gmail.com> In-Reply-To: Date: Wed, 15 Aug 2012 19:16:51 +0200 Message-ID: <008201cd7b09$c44f0ed0$4ced2c70$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0083_01CD7B1A.87DB3A30" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFM/VlsLWUUBwuvWjT5seMrvYeAmQJvL0GbAjiJEHMBkpDbuQJNqn6UAo7Cq90BwIuCfgHI6I13Ajy/Ug8BBkj53QKabmf2Ad/79xaXqSgNYA== Content-Language: en-us Cc: clue@ietf.org Subject: Re: [clue] Fwd: #11: RTP header extension for Capture ID 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, 15 Aug 2012 16:18:10 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0083_01CD7B1A.87DB3A30 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Andy, The CLUE charter is not to replace SDP, so negotiating simulcast is the requirement you want to address. There are two questions: 1. Should CLUE address it if there is no current SDP way (only document I found was draft-westerlund-avtcore-multistream-and-simulcast-00 expired on January) 2. Does it require having the consumer define the capture ID. As for pre-declaration of SSRC , I do not see the problem in the topologies that use mixer based SSRCs which is very common use today. Saying that there is a big number is not correct when the mixer/MCU creates the advertisement to each participant. I do not have any proof for such case. I agree that when the mixer will relay the SSRCs the number can be large and there is no need to define the SSRCs in the SDP from the mixer since the mixer will not even know all the SSRCs from all the sources. What we presented is to have the SSRC for the static case and send a dynamic change with the media (if we use RTP header extension). The mixer knows which topology it is using and can decide if to use static mapping and/or dynamic mapping. For most MCUs today static mapping will be enough and there will be no need to send the RTP header extension at all. Roni From: Andy Pepperell [mailto:apeppere@gmail.com] Sent: 15 August, 2012 5:15 PM To: Roni Even Cc: Roni even; clue@ietf.org Subject: Re: [clue] Fwd: #11: RTP header extension for Capture ID Hi Roni, I'm not sure of the validity of needing simulcast defined in SDP before we can start to think about it in CLUE. The messages and mechanisms as currently defined in CLUE give us simulcast functionality without the need for SDP additions (which wouldn't necessarily be a good fit for CLUE anyway, just like the pre-declaration of SSRC values doesn't scale all that well to all CLUE multi-stream use cases). >If you can point me to how to describe simulcast in SDP the issue can be solved. As above, I don't believe this is a prerequisite at all for us to be able to make progress in CLUE. Or, alternatively, introducing dependencies on such general solutions which may or may not be in the pipeline would seem likely only to impede progress on CLUE (IMHO, of course!). Regards, Andy On Wed, Aug 15, 2012 at 1:28 PM, Roni Even wrote: Hi Andy, I think this is an SDP problem. If you can point me to how to describe simulcast in SDP the issue can be solved. If not then we need to solve it for the general case and not only for CLUE Roni From: Andy Pepperell [mailto:apeppere@gmail.com] Sent: 15 August, 2012 12:34 PM To: Roni even Cc: Roni Even; clue@ietf.org Subject: Re: [clue] Fwd: #11: RTP header extension for Capture ID Hi Roni, The main complexities I'd see with that approach is the simulcast aspect - the provider may have the potential to supply, say, 4 different captures but the consumer could (encoding groups permitting) ask for 4 different encodings of the same capture or 1 encoding of each capture, and the SSRC / header extension ID allocation scheme has to work for all cases. The only way I can see for this to work would be for the provider's advertisement to include a header extension ID or SSRC value associated with each of its encoding groups' constituent potential encodings - that way the consumer would know from its own capture instantiation <--> encoding mapping which ID or SSRC the provider would be using. This has been discussed before and from what I recall (these aren't necessarily my reasons): - it's seen as advantageous for the consumer to allocate the IDs so that it can apply some structure to them (e.g. some sort of hardware routing info) - it's maybe also advantageous to decouple the consumer-side multi-stream demultiplexing from encoding groups' [potential] encodings (if this latter were subject to further / future modifications, for instance in order to cope with some more complex / flexible encoding cases that have been discussed, we wouldn't necessarily want to have to revisit the RTP multi-stream handling). Is this kind of in line with what you were thinking, or did you some other thoughts on where / how the provider would allocate and indicate these? Regards, Andy On Wed, Aug 15, 2012 at 10:48 AM, Roni even wrote: Hi Andy, Yes the provider should allocate the ID since he is defining the captures and the SSRCs Roni _____ From: clue-bounces@ietf.org [clue-bounces@ietf.org] on behalf of Andy Pepperell [apeppere@gmail.com] Sent: Wednesday, August 15, 2012 11:57 To: Roni Even Cc: clue@ietf.org Subject: Re: [clue] Fwd: #11: RTP header extension for Capture ID Hi Roni, I'm not sure I understand the point - are you asking why the consumer is assigning the IDs rather than the provider? or, taking it further, are you proposing that the provider allocate the IDs? Andy On Wed, Aug 15, 2012 at 10:19 AM, Roni Even wrote: Andy, I fail to understand why the consumer needs to define the mapping ID for a mapping done by the provider Roni From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Andy Pepperell Sent: 15 August, 2012 9:48 AM To: christer.holmberg@ericsson.com Cc: clue@ietf.org Subject: Re: [clue] Fwd: #11: RTP header extension for Capture ID Hi Christer, >Is there a reason why we can't use the SSRC? Or, can multiple captures share the same SSRC? I don't think I'm disagreeing here with anything that Roni or Paul are saying, but was thinking that the phrase "use the SSRC" potentially covers a few different cases... - If we're talking about declaring SSRC values in advance in SDP, this is likely to cause scalability issues with CLUE (more so than with, say, current webrtc implementations) because of the potential for a large number of CLUE streams in MCU cases. - The current RTP header extension proposal involves the consumer telling the provider an ID to use in the RTP header extension for each instantiated capture, which the consumer can then use to separate the multiple capture instantiations when they are received. It would clearly be reasonably straightforward for the CLUE consumer stream choice message to instead indicate an SSRC here instead of an ID to be put in an RTP header extension, but as Paul points out, this means that the consumer then loses the ability to distinguish stream changes within a switched capture (modulo CSRC usage). >[Paul] >For instance, for the switched case it would then be necessary to assign an ssrc for the switched capture... Agreed, though I think the SSRC assignment would have to be on the basis of the switched capture's *instantiation* rather than the switched capture itself - with the simulcast aspects of CLUE as currently defined, mappings can't be on the basis of just capture IDs as a consumer may request multiple instantiations of the same capture from the provider, and so a simple SSRC <--> capture ID mapping would not be sufficient. Regards, Andy On Tue, Aug 14, 2012 at 9:40 PM, Paul Kyzivat wrote: On 8/14/12 5:17 PM, Roni Even wrote: Hi Christer, This works for static SSRCs when the mixer uses its own SSRC. The problem is in the switching case when using the source SSRC. An example is when a three camera system has two captures to send to a two monitor system. The three camera system may send first the left and center camera but when switching to center and right camera the center camera will switch from right capture to left capture. This was discussed in my presentation in CLUE about mapping RTP streams. AFAIK it *could* work using SSRC. But then there are different constraints on how RTP is used. For instance, for the switched case it would then be necessary to assign an ssrc for the switched capture, and indicate the source via csrc. It also then means that if a source is moved from one switched capture to a different one, the recipient won't know that it is the *same* RTP stream. And that affects the number of iframes transmitted, etc. tradeoffs! Thanks, Paul Roni -----Original Message----- From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Christer Holmberg Sent: 14 August, 2012 9:38 PM To: Mary Barnes; CLUE Subject: Re: [clue] Fwd: #11: RTP header extension for Capture ID Hi, A silly question: Is there a reason why we can't use the SSRC? Or, can multiple captures share the same SSRC? Regards, Christer ________________________________ From: clue-bounces@ietf.org [clue-bounces@ietf.org] On Behalf Of Mary Barnes [mary.ietf.barnes@gmail.com] Sent: Monday, August 13, 2012 10:37 PM To: CLUE Subject: [clue] Fwd: #11: RTP header extension for Capture ID Hi all, I have updated/closed the issues as discussed at the meeting (and captured in the minutes): http://www.ietf.org/proceedings/84/minutes/minutes-84-clue I decided to open a ticket to track this issue since it does require some mailing list discussion and hopefully, this will trigger that. The action items from the meeting that are not related to issues are updates to documents - i.e., new data model document and adding telemedical use case to the WG use case document. Mary. ---------- Forwarded message ---------- From: clue issue tracker >> Date: Mon, Aug 13, 2012 at 2:33 PM Subject: [clue] #11: RTP header extension for Capture ID To: clue-chairs@tools.ietf.org, mary.ietf.barnes@gmail.com Cc: clue@ietf.org #11: RTP header extension for Capture ID Is an RTP header extension needed to transport a capture ID (per draft- lennox-clue-rtp-usage-04)? -- -----------------------------------+--------------------------- Reporter: mary.ietf.barnes@. | Owner: clue-chairs@. Type: defect | Status: new Priority: major | Milestone: milestone1 Component: charter | Version: 1.0 Severity: Candidate WG Document | Keywords: RTP -----------------------------------+--------------------------- Ticket URL: 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 ------=_NextPart_000_0083_01CD7B1A.87DB3A30 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Andy,

The CLUE charter is not to replace SDP, so negotiating simulcast is = the requirement you want to address.

There are two questions:

 

1.       = Should CLUE address it if there is no current SDP way (only document = I found was draft-westerlund-avtcore-multistream-and-simulcast-00 = expired on January)

2.       = Does it require having the consumer define the capture = ID.

 

As for pre-declaration of SSRC , I do not see the problem in the = topologies that use mixer based SSRCs which is very common use today. = Saying that there is a big number is not correct when the mixer/MCU = creates the advertisement  to each participant.  I do not have = any proof for such case.  I agree that when the mixer will relay = the SSRCs the number can be large and there is no need to define the = SSRCs in the SDP from the mixer since the mixer will not even know all = the SSRCs from all the sources. What we presented is to have the SSRC = for the static case and send a dynamic change with the media (if we use = RTP header extension). The mixer knows which topology it is using and = can decide if to use static mapping and/or dynamic mapping. For most = MCUs today static mapping will be enough and there will be no need to = send the RTP header extension at all.

 

Roni

 

From:= = Andy Pepperell [mailto:apeppere@gmail.com]
Sent: 15 August, = 2012 5:15 PM
To: Roni Even
Cc: Roni even; = clue@ietf.org
Subject: Re: [clue] Fwd: #11: RTP header = extension for Capture ID

 

Hi = Roni,

 

I'm not sure of the validity of needing simulcast = defined in SDP before we can start to think about it in CLUE. The = messages and mechanisms as currently defined in CLUE give us simulcast = functionality without the need for SDP additions (which wouldn't = necessarily be a good fit for CLUE anyway, just like the pre-declaration = of SSRC values doesn't scale all that well to all CLUE multi-stream use = cases).

 

>If you can point me to how to describe simulcast = in SDP the issue can be solved.

 

As above, I don't believe this is a prerequisite at = all for us to be able to make progress in CLUE. Or, alternatively, = introducing dependencies on such general solutions which may or may not = be in the pipeline would seem likely only to impede progress on CLUE = (IMHO, of course!).

 

Regards,

 

Andy

 

On Wed, Aug 15, 2012 at 1:28 PM, Roni Even <ron.even.tlv@gmail.com> = wrote:

Hi Andy,

I think this is an SDP problem. If you can point me to how to = describe simulcast in SDP the issue can be solved. If not then we need = to solve it for the general case and not only for = CLUE

Roni

 

From:= = Andy Pepperell [mailto:apeppere@gmail.com]
Sent: 15 August, = 2012 12:34 PM
To: Roni even
Cc: Roni Even; clue@ietf.org


Subject: Re: [clue] Fwd: #11: RTP header = extension for Capture ID

 <= /o:p>

Hi = Roni,

 <= /o:p>

The main = complexities I'd see with that approach is the simulcast aspect - the = provider may have the potential to supply, say, 4 different captures but = the consumer could (encoding groups permitting) ask for 4 different = encodings of the same capture or 1 encoding of each capture, and the = SSRC / header extension ID allocation scheme has to work for all = cases.

 <= /o:p>

The only = way I can see for this to work would be for the provider's advertisement = to include a header extension ID or SSRC value associated with each of = its encoding groups' constituent potential encodings - that way the = consumer would know from its own capture instantiation <--> = encoding mapping which ID or SSRC the provider would be using. This has = been discussed before and from what I recall (these aren't necessarily = my reasons):

 <= /o:p>

- it's seen = as advantageous for the consumer to allocate the IDs so that it can = apply some structure to them (e.g. some sort of hardware routing = info)

 <= /o:p>

- it's = maybe also advantageous to decouple the consumer-side multi-stream = demultiplexing from encoding groups' [potential] encodings (if this = latter were subject to further / future modifications, for instance in = order to cope with some more complex / flexible encoding cases that have = been discussed, we wouldn't necessarily want to have to revisit the RTP = multi-stream handling).

 <= /o:p>

Is this = kind of in line with what you were thinking, or did you some other = thoughts on where / how the provider would allocate and indicate = these?

 <= /o:p>

Regards,

 <= /o:p>

Andy

 <= /p>

On Wed, Aug = 15, 2012 at 10:48 AM, Roni even <Even.roni@huawei.com> = wrote:

Hi = Andy,

Yes the = provider should allocate the ID since he is defining the captures = and the SSRCs

Roni<= o:p>

From: clue-bounces@ietf.org [clue-bounces@ietf.org] on behalf of Andy Pepperell = [apeppere@gmail.com]
Sent: Wednesday, = August 15, 2012 11:57
To: Roni = Even


Cc: clue@ietf.org
Subject: Re: [clue] Fwd: = #11: RTP header extension for Capture = ID

 <= /o:p>

Hi Roni, =

 <= /o:p>

I'm not = sure I understand the point - are you asking why the consumer is = assigning the IDs rather than the provider? or, taking it further, are = you proposing that the provider allocate the = IDs?

 <= /o:p>

Andy

 <= /p>

On Wed, Aug = 15, 2012 at 10:19 AM, Roni Even <ron.even.tlv@gmail.com> = wrote:

Andy,

I fail to understand why the consumer needs to define the mapping ID = for a mapping done by the provider

Roni

 <= /o:p>

From:= = clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Andy = Pepperell
Sent: 15 August, 2012 9:48 AM
To: christer.holmberg@ericsson.com
Cc: clue@ietf.org


Subje= ct: Re: [clue] Fwd: #11: RTP header extension for Capture = ID

 <= /o:p>

Hi = Christer,

 <= /o:p>

>Is = there a reason why we can't use the SSRC? Or, can multiple captures = share the same SSRC?

 <= /o:p>

I don't = think I'm disagreeing here with anything that Roni or Paul are saying, = but was thinking that the phrase "use the SSRC" potentially = covers a few different cases...

 <= /o:p>

- If we're = talking about declaring SSRC values in advance in SDP, this is likely to = cause scalability issues with CLUE (more so than with, say, current = webrtc implementations) because of the potential for a large number of = CLUE streams in MCU cases.

 <= /o:p>

- The = current RTP header extension proposal involves the consumer telling the = provider an ID to use in the RTP header extension for each instantiated = capture, which the consumer can then use to separate the multiple = capture instantiations when they are received. It would clearly be = reasonably straightforward for the CLUE consumer stream choice message = to instead indicate an SSRC here instead of an ID to be put in an RTP = header extension, but as Paul points out, this means that the consumer = then loses the ability to distinguish stream changes within a switched = capture (modulo CSRC usage).

 <= /o:p>

>[Paul]

>For = instance, for the switched case it would then be necessary to assign an = ssrc for the switched capture...

 <= /o:p>

Agreed, = though I think the SSRC assignment would have to be on the basis of the = switched capture's *instantiation* rather than the switched capture = itself - with the simulcast aspects of CLUE as currently defined, = mappings can't be on the basis of just capture IDs as a consumer may = request multiple instantiations of the same capture from the provider, = and so a simple SSRC <--> capture ID mapping would not be = sufficient.

 <= /o:p>

Regards,

 <= /o:p>

Andy

 <= /o:p>

 <= /o:p>

On Tue, Aug = 14, 2012 at 9:40 PM, Paul Kyzivat <pkyzivat@alum.mit.edu> = wrote:

On 8/14/12 = 5:17 PM, Roni Even wrote:

Hi = Christer,
This works for static SSRCs when the mixer uses its own = SSRC. The problem is
in the switching case when using the source = SSRC. An example is when a three
camera system has two captures to = send to a two monitor system. The three
camera system may send first = the left and center camera but when switching
to center and right = camera the center camera will switch from right capture
to left = capture.
This was discussed in my presentation in CLUE about mapping = RTP streams.

 <= /o:p>

AFAIK it = *could* work using SSRC. But then there are different constraints on how = RTP is used.

For instance, for the switched case it would then be = necessary to assign an ssrc for the switched capture, and indicate the = source via csrc.

It also then means that if a source is moved = from one switched capture to a different one, the recipient won't know = that it is the *same* RTP stream. And that affects the number of iframes = transmitted, etc.

tradeoffs!

        = Thanks,
        = Paul

 <= /p>

Roni

-----O= riginal Message-----
From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of
Christer = Holmberg
Sent: 14 August, 2012 9:38 PM
To: Mary Barnes; = CLUE
Subject: Re: [clue] Fwd: #11: RTP header extension for Capture = ID

Hi,

A silly question:

Is there a reason why we = can't use the SSRC? Or, can multiple captures share
the same = SSRC?

Regards,

Christer

____________________________= ____
From: clue-bounces@ietf.org [clue-bounces@ietf.org] On Behalf Of Mary = Barnes
[mary.ietf.barnes@gmail.com]
Sent: Monday, = August 13, 2012 10:37 PM
To: CLUE
Subject: [clue] Fwd: #11: RTP = header extension for Capture ID

Hi all,

I have = updated/closed the issues as discussed at the meeting (and = captured
in the minutes):  http://www.ietf.org/proceedings/84/minutes/minutes-84-c= lue

I decided to open a ticket to track this issue since it = does require some
mailing list discussion and hopefully, this will = trigger that.

The action items from the meeting that are not = related to issues are updates
to documents - i.e., new data model = document and adding telemedical use case
to the WG use case = document.

Mary.

---------- Forwarded message = ----------
From: clue issue tracker
<trac+clue@trac.tools.ietf.org<mailto:trac%2Bclue@trac.tools.ietf.org>>
Date: = Mon, Aug 13, 2012 at 2:33 PM
Subject: [clue] #11: RTP header = extension for Capture ID
To: clue-chairs@tools.ietf.org<mailto:clue-chairs@tools.ietf.org>,
mary.ietf.barnes@gmail.com<mailto:mary.ietf.barnes@gmail.com>
Cc: clue@ietf.org<mailto:clue@ietf.org>


#11: RTP header = extension for Capture ID

  Is an RTP header extension needed = to transport a capture ID (per = draft-
lennox-clue-rtp-usage-04)?

--
-----------------------= ------------+---------------------------
  Reporter:  mary.ietf.barnes@.     |     =  Owner:  clue-chairs@.
      Type: =  defect                 | =     Status:  new
  Priority:  major   =                | =  Milestone:  milestone1
Component:  charter   =              |    Version: =  1.0
  Severity:  Candidate WG Document  |   = Keywords: =  RTP
-----------------------------------+------------------------= ---

Ticket URL:<http://grenache.tools.ietf.org/wg/clue/trac/ticket/11>
clue<http://tools.ietf.org/wg/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

 <= /o:p>

 <= /o:p>

 <= /o:p>

 

------=_NextPart_000_0083_01CD7B1A.87DB3A30-- From pkyzivat@alum.mit.edu Wed Aug 15 09:27: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 CCD0A21F859C for ; Wed, 15 Aug 2012 09:27:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.293 X-Spam-Level: X-Spam-Status: No, score=-2.293 tagged_above=-999 required=5 tests=[AWL=0.306, 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 RBVTEAYy1ssD for ; Wed, 15 Aug 2012 09:27:37 -0700 (PDT) Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [76.96.59.227]) by ietfa.amsl.com (Postfix) with ESMTP id 8A28821F8779 for ; Wed, 15 Aug 2012 09:27:37 -0700 (PDT) Received: from omta12.westchester.pa.mail.comcast.net ([76.96.62.44]) by qmta12.westchester.pa.mail.comcast.net with comcast id mz851j0020xGWP85C4Tgg5; Wed, 15 Aug 2012 16:27:40 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta12.westchester.pa.mail.comcast.net with comcast id n4T91j00K3ZTu2S3Y4T9ua; Wed, 15 Aug 2012 16:27:09 +0000 Message-ID: <502BCDF8.4020301@alum.mit.edu> Date: Wed, 15 Aug 2012 12:27:36 -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: <068.5ca029063d5e7080dd9f9169d703adcf@trac.tools.ietf.org> <7F2072F1E0DE894DA4B517B93C6A0585340868365E@ESESSCMS0356.eemea.ericsson.se> <005201cd7a62$40e62260$c2b26720$@gmail.com> <502AB7B1.4070506@alum.mit.edu> <003901cd7ac7$22323a10$6696ae30$@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] Fwd: #11: RTP header extension for Capture ID 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, 15 Aug 2012 16:27:38 -0000 Andy, There is clearly a terminology problem here. If each capture+encoding pair requires a distinct ID, then that ID cannot properly be called a "Capture ID". Suppose a separate capture+encoding-ID is carried as an RTP extension. Even so, if the same capture is sent in two encodings in the same RTP session, isn't it *necessary* that each have a distinct SSRC? If so, that will be a problem if the goal is to pass the source SSRCs through switched captures. Thanks, Paul (as individual) On 8/15/12 6:34 AM, Andy Pepperell wrote: > Hi Roni, > > The main complexities I'd see with that approach is the simulcast aspect > - the provider may have the potential to supply, say, 4 different > captures but the consumer could (encoding groups permitting) ask for 4 > different encodings of the same capture or 1 encoding of each capture, > and the SSRC / header extension ID allocation scheme has to work for all > cases. > > The only way I can see for this to work would be for the provider's > advertisement to include a header extension ID or SSRC value associated > with each of its encoding groups' constituent potential encodings - that > way the consumer would know from its own capture instantiation <--> > encoding mapping which ID or SSRC the provider would be using. This has > been discussed before and from what I recall (these aren't necessarily > my reasons): > > - it's seen as advantageous for the consumer to allocate the IDs so that > it can apply some structure to them (e.g. some sort of hardware routing > info) > > - it's maybe also advantageous to decouple the consumer-side > multi-stream demultiplexing from encoding groups' [potential] encodings > (if this latter were subject to further / future modifications, for > instance in order to cope with some more complex / flexible encoding > cases that have been discussed, we wouldn't necessarily want to have to > revisit the RTP multi-stream handling). > > Is this kind of in line with what you were thinking, or did you some > other thoughts on where / how the provider would allocate and indicate > these? > > Regards, > > Andy > > > On Wed, Aug 15, 2012 at 10:48 AM, Roni even > wrote: > > Hi Andy, > > Yes the provider shouldallocate the ID since he is defining the > captures and the SSRCs > > Roni > > ------------------------------------------------------------------------ > *From:* clue-bounces@ietf.org > [clue-bounces@ietf.org ] on behalf of > Andy Pepperell [apeppere@gmail.com ] > *Sent:* Wednesday, August 15, 2012 11:57 > *To:* Roni Even > > *Cc:* clue@ietf.org > *Subject:* Re: [clue] Fwd: #11: RTP header extension for Capture ID > > Hi Roni, > > I'm not sure I understand the point - are you asking why the > consumer is assigning the IDs rather than the provider? or, taking > it further, are you proposing that the provider allocate the IDs? > > Andy > > > On Wed, Aug 15, 2012 at 10:19 AM, Roni Even > wrote: > > Andy,____ > > I fail to understand why the consumer needs to define the > mapping ID for a mapping done by the provider____ > > Roni____ > > ____ > > *From:*clue-bounces@ietf.org > [mailto:clue-bounces@ietf.org ] > *On Behalf Of *Andy Pepperell > *Sent:* 15 August, 2012 9:48 AM > *To:* christer.holmberg@ericsson.com > > *Cc:* clue@ietf.org > > > *Subject:* Re: [clue] Fwd: #11: RTP header extension for Capture > ID____ > > ____ > > Hi Christer,____ > > ____ > > >Is there a reason why we can't use the SSRC? Or, can multiple > captures share the same SSRC?____ > > ____ > > I don't think I'm disagreeing here with anything that Roni or > Paul are saying, but was thinking that the phrase "use the SSRC" > potentially covers a few different cases...____ > > ____ > > - If we're talking about declaring SSRC values in advance in > SDP, this is likely to cause scalability issues with CLUE (more > so than with, say, current webrtc implementations) because of > the potential for a large number of CLUE streams in MCU cases.____ > > ____ > > - The current RTP header extension proposal involves the > consumer telling the provider an ID to use in the RTP header > extension for each instantiated capture, which the consumer can > then use to separate the multiple capture instantiations when > they are received. It would clearly be reasonably > straightforward for the CLUE consumer stream choice message to > instead indicate an SSRC here instead of an ID to be put in an > RTP header extension, but as Paul points out, this means that > the consumer then loses the ability to distinguish stream > changes within a switched capture (modulo CSRC usage).____ > > ____ > > >[Paul]____ > > >For instance, for the switched case it would then be necessary > to assign an ssrc for the switched capture...____ > > ____ > > Agreed, though I think the SSRC assignment would have to be on > the basis of the switched capture's *instantiation* rather than > the switched capture itself - with the simulcast aspects of CLUE > as currently defined, mappings can't be on the basis of just > capture IDs as a consumer may request multiple instantiations of > the same capture from the provider, and so a simple SSRC <--> > capture ID mapping would not be sufficient.____ > > ____ > > Regards,____ > > ____ > > Andy____ > > ____ > > ____ > > On Tue, Aug 14, 2012 at 9:40 PM, Paul Kyzivat > > wrote:____ > > On 8/14/12 5:17 PM, Roni Even wrote:____ > > Hi Christer, > This works for static SSRCs when the mixer uses its own SSRC. > The problem is > in the switching case when using the source SSRC. An example is > when a three > camera system has two captures to send to a two monitor system. > The three > camera system may send first the left and center camera but when > switching > to center and right camera the center camera will switch from > right capture > to left capture. > This was discussed in my presentation in CLUE about mapping RTP > streams.____ > > ____ > > AFAIK it *could* work using SSRC. But then there are different > constraints on how RTP is used. > > For instance, for the switched case it would then be necessary > to assign an ssrc for the switched capture, and indicate the > source via csrc. > > It also then means that if a source is moved from one switched > capture to a different one, the recipient won't know that it is > the *same* RTP stream. And that affects the number of iframes > transmitted, etc. > > tradeoffs! > > Thanks, > Paul____ > > ____ > > Roni > > -----Original Message----- > From: clue-bounces@ietf.org > [mailto:clue-bounces@ietf.org > ] On Behalf Of > Christer Holmberg > Sent: 14 August, 2012 9:38 PM > To: Mary Barnes; CLUE > Subject: Re: [clue] Fwd: #11: RTP header extension for > Capture ID > > Hi, > > A silly question: > > Is there a reason why we can't use the SSRC? Or, can > multiple captures share > the same SSRC? > > Regards, > > Christer > > ________________________________ > From: clue-bounces@ietf.org > [clue-bounces@ietf.org ] On > Behalf Of Mary Barnes > [mary.ietf.barnes@gmail.com ] > Sent: Monday, August 13, 2012 10:37 PM > To: CLUE > Subject: [clue] Fwd: #11: RTP header extension for Capture ID > > Hi all, > > I have updated/closed the issues as discussed at the meeting > (and captured > in the minutes): > http://www.ietf.org/proceedings/84/minutes/minutes-84-clue > > I decided to open a ticket to track this issue since it does > require some > mailing list discussion and hopefully, this will trigger that. > > The action items from the meeting that are not related to > issues are updates > to documents - i.e., new data model document and adding > telemedical use case > to the WG use case document. > > Mary. > > ---------- Forwarded message ---------- > From: clue issue tracker > >> > Date: Mon, Aug 13, 2012 at 2:33 PM > Subject: [clue] #11: RTP header extension for Capture ID > To: clue-chairs@tools.ietf.org > >, > mary.ietf.barnes@gmail.com > > > Cc: clue@ietf.org > > > > > #11: RTP header extension for Capture ID > > Is an RTP header extension needed to transport a capture > ID (per draft- > lennox-clue-rtp-usage-04)? > > -- > -----------------------------------+--------------------------- > Reporter: mary.ietf.barnes@ . > | Owner: clue-chairs@. > Type: defect | Status: new > Priority: major | Milestone: milestone1 > Component: charter | Version: 1.0 > Severity: Candidate WG Document | Keywords: RTP > -----------------------------------+--------------------------- > > Ticket > URL: > 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 paul.witty@silverflare.com Wed Aug 15 09:39: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 0387621E80D5 for ; Wed, 15 Aug 2012 09:39:20 -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 jkK3IRiUuK5n for ; Wed, 15 Aug 2012 09:39:18 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 80CC321F85D4 for ; Wed, 15 Aug 2012 09:39:18 -0700 (PDT) Received: by eaai11 with SMTP id i11so532904eaa.31 for ; Wed, 15 Aug 2012 09:39:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=l+rY7ZT1NZBV6vC7LX+EG9KoN9xVRUC3slFhELO+lcs=; b=LmUk4Trs7tmbLAzlWU7/Nr2Nnw/7bd9rS+30i+4vTcVi64PT2mLbr2pzOUhujE+pXE lazmoYRBsGf7zrF91L3+qwD3iJiFrvzyArP9v1u9cCWgJTL5PM1ig0FClCXIQUD6Ag8J QsNBsh/eACYPQaNMX1xUBNiQsDJFGoZ6oaHuc9JCN/vsjla1v5dVhcf9Oaew7c7hcBAC OKr5fYR7+ndeRdJk+6Ee0ZsN6x+Rjir4+nuUBEBKgTIdU7UsM7ZEr7wb00P1duqiKS0x 4/gUULkwAWoZnVzgeqi7ltary6bdYgCKVjPYIJUWVK7g3U7pAS094UVB4tZ/miW29De9 dMnw== Received: by 10.14.204.72 with SMTP id g48mr25158201eeo.45.1345048757486; Wed, 15 Aug 2012 09:39:17 -0700 (PDT) Received: from [10.1.2.227] (82-70-15-70.dsl.in-addr.zen.co.uk. [82.70.15.70]) by mx.google.com with ESMTPS id h42sm5273507eem.5.2012.08.15.09.39.16 (version=SSLv3 cipher=OTHER); Wed, 15 Aug 2012 09:39:16 -0700 (PDT) Message-ID: <502BD049.5090209@silverflare.com> Date: Wed, 15 Aug 2012 17:37:29 +0100 From: Paul Witty User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120723 Thunderbird/14.0 MIME-Version: 1.0 To: clue@ietf.org References: <068.5ca029063d5e7080dd9f9169d703adcf@trac.tools.ietf.org> <7F2072F1E0DE894DA4B517B93C6A0585340868365E@ESESSCMS0356.eemea.ericsson.se> <005201cd7a62$40e62260$c2b26720$@gmail.com> <502AB7B1.4070506@alum.mit.edu> <003901cd7ac7$22323a10$6696ae30$@gmail.com> <502BCDF8.4020301@alum.mit.edu> In-Reply-To: <502BCDF8.4020301@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQlr144itzx9Ofi2ivjNRHNAF+5NAB7e0Ck8kTlkhUyn5KzIBnXkAkbUlGc+Zc9nRVRYrq/8 Subject: Re: [clue] Fwd: #11: RTP header extension for Capture ID 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, 15 Aug 2012 16:39:20 -0000 Each encoded media stream must have a distinct SSRC. If a source is sent in two separate requested captures (i.e. simulcasting of two resolutions by a transcoding middle box), then the two encodings of the same capture will have distinct SSRCs, but the SSRC of the original encoding of the source as a CSRC. If we want to send the same encoding over two requested captures (i.e. requesting both a single stream of loudest speaker, and left/centre/right streams from a single endpoint, where the former will always be one of the latter), we can use multiple instances of the RTP extension in the RTP header, one for each of the requested captures. Paul On 15/08/12 17:27, Paul Kyzivat wrote: > Andy, > > There is clearly a terminology problem here. If each capture+encoding > pair requires a distinct ID, then that ID cannot properly be called a > "Capture ID". > > Suppose a separate capture+encoding-ID is carried as an RTP extension. > Even so, if the same capture is sent in two encodings in the same RTP > session, isn't it *necessary* that each have a distinct SSRC? If so, > that will be a problem if the goal is to pass the source SSRCs through > switched captures. > > Thanks, > Paul (as individual) > > On 8/15/12 6:34 AM, Andy Pepperell wrote: >> Hi Roni, >> >> The main complexities I'd see with that approach is the simulcast aspect >> - the provider may have the potential to supply, say, 4 different >> captures but the consumer could (encoding groups permitting) ask for 4 >> different encodings of the same capture or 1 encoding of each capture, >> and the SSRC / header extension ID allocation scheme has to work for all >> cases. >> >> The only way I can see for this to work would be for the provider's >> advertisement to include a header extension ID or SSRC value associated >> with each of its encoding groups' constituent potential encodings - that >> way the consumer would know from its own capture instantiation <--> >> encoding mapping which ID or SSRC the provider would be using. This has >> been discussed before and from what I recall (these aren't necessarily >> my reasons): >> >> - it's seen as advantageous for the consumer to allocate the IDs so that >> it can apply some structure to them (e.g. some sort of hardware routing >> info) >> >> - it's maybe also advantageous to decouple the consumer-side >> multi-stream demultiplexing from encoding groups' [potential] encodings >> (if this latter were subject to further / future modifications, for >> instance in order to cope with some more complex / flexible encoding >> cases that have been discussed, we wouldn't necessarily want to have to >> revisit the RTP multi-stream handling). >> >> Is this kind of in line with what you were thinking, or did you some >> other thoughts on where / how the provider would allocate and indicate >> these? >> >> Regards, >> >> Andy >> >> >> On Wed, Aug 15, 2012 at 10:48 AM, Roni even > > wrote: >> >> Hi Andy, >> >> Yes the provider shouldallocate the ID since he is defining the >> captures and the SSRCs >> >> Roni >> >> ------------------------------------------------------------------------ >> *From:* clue-bounces@ietf.org >> [clue-bounces@ietf.org ] on behalf of >> Andy Pepperell [apeppere@gmail.com ] >> *Sent:* Wednesday, August 15, 2012 11:57 >> *To:* Roni Even >> >> *Cc:* clue@ietf.org >> *Subject:* Re: [clue] Fwd: #11: RTP header extension for Capture ID >> >> Hi Roni, >> >> I'm not sure I understand the point - are you asking why the >> consumer is assigning the IDs rather than the provider? or, taking >> it further, are you proposing that the provider allocate the IDs? >> >> Andy >> >> >> On Wed, Aug 15, 2012 at 10:19 AM, Roni Even > > wrote: >> >> Andy,____ >> >> I fail to understand why the consumer needs to define the >> mapping ID for a mapping done by the provider____ >> >> Roni____ >> >> ____ >> >> *From:*clue-bounces@ietf.org >> [mailto:clue-bounces@ietf.org ] >> *On Behalf Of *Andy Pepperell >> *Sent:* 15 August, 2012 9:48 AM >> *To:* christer.holmberg@ericsson.com >> >> *Cc:* clue@ietf.org >> >> >> *Subject:* Re: [clue] Fwd: #11: RTP header extension for Capture >> ID____ >> >> ____ >> >> Hi Christer,____ >> >> ____ >> >> >Is there a reason why we can't use the SSRC? Or, can multiple >> captures share the same SSRC?____ >> >> ____ >> >> I don't think I'm disagreeing here with anything that Roni or >> Paul are saying, but was thinking that the phrase "use the SSRC" >> potentially covers a few different cases...____ >> >> ____ >> >> - If we're talking about declaring SSRC values in advance in >> SDP, this is likely to cause scalability issues with CLUE (more >> so than with, say, current webrtc implementations) because of >> the potential for a large number of CLUE streams in MCU >> cases.____ >> >> ____ >> >> - The current RTP header extension proposal involves the >> consumer telling the provider an ID to use in the RTP header >> extension for each instantiated capture, which the consumer can >> then use to separate the multiple capture instantiations when >> they are received. It would clearly be reasonably >> straightforward for the CLUE consumer stream choice message to >> instead indicate an SSRC here instead of an ID to be put in an >> RTP header extension, but as Paul points out, this means that >> the consumer then loses the ability to distinguish stream >> changes within a switched capture (modulo CSRC usage).____ >> >> ____ >> >> >[Paul]____ >> >> >For instance, for the switched case it would then be necessary >> to assign an ssrc for the switched capture...____ >> >> ____ >> >> Agreed, though I think the SSRC assignment would have to be on >> the basis of the switched capture's *instantiation* rather than >> the switched capture itself - with the simulcast aspects of CLUE >> as currently defined, mappings can't be on the basis of just >> capture IDs as a consumer may request multiple instantiations of >> the same capture from the provider, and so a simple SSRC <--> >> capture ID mapping would not be sufficient.____ >> >> ____ >> >> Regards,____ >> >> ____ >> >> Andy____ >> >> ____ >> >> ____ >> >> On Tue, Aug 14, 2012 at 9:40 PM, Paul Kyzivat >> > >> wrote:____ >> >> On 8/14/12 5:17 PM, Roni Even wrote:____ >> >> Hi Christer, >> This works for static SSRCs when the mixer uses its own SSRC. >> The problem is >> in the switching case when using the source SSRC. An example is >> when a three >> camera system has two captures to send to a two monitor system. >> The three >> camera system may send first the left and center camera but when >> switching >> to center and right camera the center camera will switch from >> right capture >> to left capture. >> This was discussed in my presentation in CLUE about mapping RTP >> streams.____ >> >> ____ >> >> AFAIK it *could* work using SSRC. But then there are different >> constraints on how RTP is used. >> >> For instance, for the switched case it would then be necessary >> to assign an ssrc for the switched capture, and indicate the >> source via csrc. >> >> It also then means that if a source is moved from one switched >> capture to a different one, the recipient won't know that it is >> the *same* RTP stream. And that affects the number of iframes >> transmitted, etc. >> >> tradeoffs! >> >> Thanks, >> Paul____ >> >> ____ >> >> Roni >> >> -----Original Message----- >> From: clue-bounces@ietf.org >> [mailto:clue-bounces@ietf.org >> ] On Behalf Of >> Christer Holmberg >> Sent: 14 August, 2012 9:38 PM >> To: Mary Barnes; CLUE >> Subject: Re: [clue] Fwd: #11: RTP header extension for >> Capture ID >> >> Hi, >> >> A silly question: >> >> Is there a reason why we can't use the SSRC? Or, can >> multiple captures share >> the same SSRC? >> >> Regards, >> >> Christer >> >> ________________________________ >> From: clue-bounces@ietf.org >> [clue-bounces@ietf.org ] On >> Behalf Of Mary Barnes >> [mary.ietf.barnes@gmail.com >> ] >> Sent: Monday, August 13, 2012 10:37 PM >> To: CLUE >> Subject: [clue] Fwd: #11: RTP header extension for >> Capture ID >> >> Hi all, >> >> I have updated/closed the issues as discussed at the meeting >> (and captured >> in the minutes): >> http://www.ietf.org/proceedings/84/minutes/minutes-84-clue >> >> I decided to open a ticket to track this issue since it does >> require some >> mailing list discussion and hopefully, this will trigger >> that. >> >> The action items from the meeting that are not related to >> issues are updates >> to documents - i.e., new data model document and adding >> telemedical use case >> to the WG use case document. >> >> Mary. >> >> ---------- Forwarded message ---------- >> From: clue issue tracker >> > > >> >> Date: Mon, Aug 13, 2012 at 2:33 PM >> Subject: [clue] #11: RTP header extension for Capture ID >> To: clue-chairs@tools.ietf.org >> > >, >> mary.ietf.barnes@gmail.com >> > > >> Cc: clue@ietf.org >> > > >> >> >> #11: RTP header extension for Capture ID >> >> Is an RTP header extension needed to transport a capture >> ID (per draft- >> lennox-clue-rtp-usage-04)? >> >> -- >> -----------------------------------+--------------------------- >> Reporter: mary.ietf.barnes@ . >> | Owner: clue-chairs@. >> Type: defect | Status: new >> Priority: major | Milestone: >> milestone1 >> Component: charter | Version: 1.0 >> Severity: Candidate WG Document | Keywords: RTP >> -----------------------------------+--------------------------- >> >> Ticket >> URL: >> 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 pkyzivat@alum.mit.edu Wed Aug 15 10:57: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 DB80921F86D5 for ; Wed, 15 Aug 2012 10:57:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.297 X-Spam-Level: X-Spam-Status: No, score=-2.297 tagged_above=-999 required=5 tests=[AWL=0.302, 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 Vi+zHevIE3kd for ; Wed, 15 Aug 2012 10:57:16 -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 8CBF921F86B6 for ; Wed, 15 Aug 2012 10:57:16 -0700 (PDT) Received: from omta14.westchester.pa.mail.comcast.net ([76.96.62.60]) by QMTA11.westchester.pa.mail.comcast.net with comcast id n52q1j0051HzFnQ5B5xKcR; Wed, 15 Aug 2012 17:57:19 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta14.westchester.pa.mail.comcast.net with comcast id n5xJ1j0083ZTu2S3a5xJRG; Wed, 15 Aug 2012 17:57:18 +0000 Message-ID: <502BE2FB.7040407@alum.mit.edu> Date: Wed, 15 Aug 2012 13:57:15 -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: <068.5ca029063d5e7080dd9f9169d703adcf@trac.tools.ietf.org> <7F2072F1E0DE894DA4B517B93C6A0585340868365E@ESESSCMS0356.eemea.ericsson.se> <005201cd7a62$40e62260$c2b26720$@gmail.com> <502AB7B1.4070506@alum.mit.edu> <003901cd7ac7$22323a10$6696ae30$@gmail.com> <502BCDF8.4020301@alum.mit.edu> <502BD049.5090209@silverflare.com> In-Reply-To: <502BD049.5090209@silverflare.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] Fwd: #11: RTP header extension for Capture ID 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, 15 Aug 2012 17:57:18 -0000 On 8/15/12 12:37 PM, Paul Witty wrote: > Each encoded media stream must have a distinct SSRC. If a source is sent > in two separate requested captures (i.e. simulcasting of two resolutions > by a transcoding middle box), then the two encodings of the same capture > will have distinct SSRCs, but the SSRC of the original encoding of the > source as a CSRC. That seems to be in conflict with wanting to send the source SSRC for switched captures. But that is also an arrangement that suggests the SSRC could be used to identify the capture+encoding. > If we want to send the same encoding over two > requested captures (i.e. requesting both a single stream of loudest > speaker, and left/centre/right streams from a single endpoint, where the > former will always be one of the latter), we can use multiple instances > of the RTP extension in the RTP header, one for each of the requested > captures. That is a situation where using the SSRC to identify the capture+encoding has a major cost in bandwidth. Thanks, Paul K > Paul > > On 15/08/12 17:27, Paul Kyzivat wrote: >> Andy, >> >> There is clearly a terminology problem here. If each capture+encoding >> pair requires a distinct ID, then that ID cannot properly be called a >> "Capture ID". >> >> Suppose a separate capture+encoding-ID is carried as an RTP extension. >> Even so, if the same capture is sent in two encodings in the same RTP >> session, isn't it *necessary* that each have a distinct SSRC? If so, >> that will be a problem if the goal is to pass the source SSRCs through >> switched captures. >> >> Thanks, >> Paul (as individual) >> >> On 8/15/12 6:34 AM, Andy Pepperell wrote: >>> Hi Roni, >>> >>> The main complexities I'd see with that approach is the simulcast aspect >>> - the provider may have the potential to supply, say, 4 different >>> captures but the consumer could (encoding groups permitting) ask for 4 >>> different encodings of the same capture or 1 encoding of each capture, >>> and the SSRC / header extension ID allocation scheme has to work for all >>> cases. >>> >>> The only way I can see for this to work would be for the provider's >>> advertisement to include a header extension ID or SSRC value associated >>> with each of its encoding groups' constituent potential encodings - that >>> way the consumer would know from its own capture instantiation <--> >>> encoding mapping which ID or SSRC the provider would be using. This has >>> been discussed before and from what I recall (these aren't necessarily >>> my reasons): >>> >>> - it's seen as advantageous for the consumer to allocate the IDs so that >>> it can apply some structure to them (e.g. some sort of hardware routing >>> info) >>> >>> - it's maybe also advantageous to decouple the consumer-side >>> multi-stream demultiplexing from encoding groups' [potential] encodings >>> (if this latter were subject to further / future modifications, for >>> instance in order to cope with some more complex / flexible encoding >>> cases that have been discussed, we wouldn't necessarily want to have to >>> revisit the RTP multi-stream handling). >>> >>> Is this kind of in line with what you were thinking, or did you some >>> other thoughts on where / how the provider would allocate and indicate >>> these? >>> >>> Regards, >>> >>> Andy >>> >>> >>> On Wed, Aug 15, 2012 at 10:48 AM, Roni even >> > wrote: >>> >>> Hi Andy, >>> >>> Yes the provider shouldallocate the ID since he is defining the >>> captures and the SSRCs >>> >>> Roni >>> >>> ------------------------------------------------------------------------ >>> *From:* clue-bounces@ietf.org >>> [clue-bounces@ietf.org ] on behalf of >>> Andy Pepperell [apeppere@gmail.com ] >>> *Sent:* Wednesday, August 15, 2012 11:57 >>> *To:* Roni Even >>> >>> *Cc:* clue@ietf.org >>> *Subject:* Re: [clue] Fwd: #11: RTP header extension for Capture ID >>> >>> Hi Roni, >>> >>> I'm not sure I understand the point - are you asking why the >>> consumer is assigning the IDs rather than the provider? or, taking >>> it further, are you proposing that the provider allocate the IDs? >>> >>> Andy >>> >>> >>> On Wed, Aug 15, 2012 at 10:19 AM, Roni Even >> > wrote: >>> >>> Andy,____ >>> >>> I fail to understand why the consumer needs to define the >>> mapping ID for a mapping done by the provider____ >>> >>> Roni____ >>> >>> ____ >>> >>> *From:*clue-bounces@ietf.org >>> [mailto:clue-bounces@ietf.org ] >>> *On Behalf Of *Andy Pepperell >>> *Sent:* 15 August, 2012 9:48 AM >>> *To:* christer.holmberg@ericsson.com >>> >>> *Cc:* clue@ietf.org >>> >>> >>> *Subject:* Re: [clue] Fwd: #11: RTP header extension for Capture >>> ID____ >>> >>> ____ >>> >>> Hi Christer,____ >>> >>> ____ >>> >>> >Is there a reason why we can't use the SSRC? Or, can multiple >>> captures share the same SSRC?____ >>> >>> ____ >>> >>> I don't think I'm disagreeing here with anything that Roni or >>> Paul are saying, but was thinking that the phrase "use the SSRC" >>> potentially covers a few different cases...____ >>> >>> ____ >>> >>> - If we're talking about declaring SSRC values in advance in >>> SDP, this is likely to cause scalability issues with CLUE (more >>> so than with, say, current webrtc implementations) because of >>> the potential for a large number of CLUE streams in MCU cases.____ >>> >>> ____ >>> >>> - The current RTP header extension proposal involves the >>> consumer telling the provider an ID to use in the RTP header >>> extension for each instantiated capture, which the consumer can >>> then use to separate the multiple capture instantiations when >>> they are received. It would clearly be reasonably >>> straightforward for the CLUE consumer stream choice message to >>> instead indicate an SSRC here instead of an ID to be put in an >>> RTP header extension, but as Paul points out, this means that >>> the consumer then loses the ability to distinguish stream >>> changes within a switched capture (modulo CSRC usage).____ >>> >>> ____ >>> >>> >[Paul]____ >>> >>> >For instance, for the switched case it would then be necessary >>> to assign an ssrc for the switched capture...____ >>> >>> ____ >>> >>> Agreed, though I think the SSRC assignment would have to be on >>> the basis of the switched capture's *instantiation* rather than >>> the switched capture itself - with the simulcast aspects of CLUE >>> as currently defined, mappings can't be on the basis of just >>> capture IDs as a consumer may request multiple instantiations of >>> the same capture from the provider, and so a simple SSRC <--> >>> capture ID mapping would not be sufficient.____ >>> >>> ____ >>> >>> Regards,____ >>> >>> ____ >>> >>> Andy____ >>> >>> ____ >>> >>> ____ >>> >>> On Tue, Aug 14, 2012 at 9:40 PM, Paul Kyzivat >>> > wrote:____ >>> >>> On 8/14/12 5:17 PM, Roni Even wrote:____ >>> >>> Hi Christer, >>> This works for static SSRCs when the mixer uses its own SSRC. >>> The problem is >>> in the switching case when using the source SSRC. An example is >>> when a three >>> camera system has two captures to send to a two monitor system. >>> The three >>> camera system may send first the left and center camera but when >>> switching >>> to center and right camera the center camera will switch from >>> right capture >>> to left capture. >>> This was discussed in my presentation in CLUE about mapping RTP >>> streams.____ >>> >>> ____ >>> >>> AFAIK it *could* work using SSRC. But then there are different >>> constraints on how RTP is used. >>> >>> For instance, for the switched case it would then be necessary >>> to assign an ssrc for the switched capture, and indicate the >>> source via csrc. >>> >>> It also then means that if a source is moved from one switched >>> capture to a different one, the recipient won't know that it is >>> the *same* RTP stream. And that affects the number of iframes >>> transmitted, etc. >>> >>> tradeoffs! >>> >>> Thanks, >>> Paul____ >>> >>> ____ >>> >>> Roni >>> >>> -----Original Message----- >>> From: clue-bounces@ietf.org >>> [mailto:clue-bounces@ietf.org >>> ] On Behalf Of >>> Christer Holmberg >>> Sent: 14 August, 2012 9:38 PM >>> To: Mary Barnes; CLUE >>> Subject: Re: [clue] Fwd: #11: RTP header extension for >>> Capture ID >>> >>> Hi, >>> >>> A silly question: >>> >>> Is there a reason why we can't use the SSRC? Or, can >>> multiple captures share >>> the same SSRC? >>> >>> Regards, >>> >>> Christer >>> >>> ________________________________ >>> From: clue-bounces@ietf.org >>> [clue-bounces@ietf.org ] On >>> Behalf Of Mary Barnes >>> [mary.ietf.barnes@gmail.com ] >>> Sent: Monday, August 13, 2012 10:37 PM >>> To: CLUE >>> Subject: [clue] Fwd: #11: RTP header extension for Capture ID >>> >>> Hi all, >>> >>> I have updated/closed the issues as discussed at the meeting >>> (and captured >>> in the minutes): >>> http://www.ietf.org/proceedings/84/minutes/minutes-84-clue >>> >>> I decided to open a ticket to track this issue since it does >>> require some >>> mailing list discussion and hopefully, this will trigger that. >>> >>> The action items from the meeting that are not related to >>> issues are updates >>> to documents - i.e., new data model document and adding >>> telemedical use case >>> to the WG use case document. >>> >>> Mary. >>> >>> ---------- Forwarded message ---------- >>> From: clue issue tracker >>> >> >> >>> >> >>> Date: Mon, Aug 13, 2012 at 2:33 PM >>> Subject: [clue] #11: RTP header extension for Capture ID >>> To: clue-chairs@tools.ietf.org >>> >> >, >>> mary.ietf.barnes@gmail.com >>> >> > >>> Cc: clue@ietf.org >>> >> > >>> >>> >>> #11: RTP header extension for Capture ID >>> >>> Is an RTP header extension needed to transport a capture >>> ID (per draft- >>> lennox-clue-rtp-usage-04)? >>> >>> -- >>> -----------------------------------+--------------------------- >>> Reporter: mary.ietf.barnes@ . >>> | Owner: clue-chairs@. >>> Type: defect | Status: new >>> Priority: major | Milestone: milestone1 >>> Component: charter | Version: 1.0 >>> Severity: Candidate WG Document | Keywords: RTP >>> -----------------------------------+--------------------------- >>> >>> Ticket >>> URL: >>> 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 > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From christer.holmberg@ericsson.com Wed Aug 15 11:34: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 1C51621F86DC for ; Wed, 15 Aug 2012 11:34:21 -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.084, 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 PcLH7GxkmsTb for ; Wed, 15 Aug 2012 11:34:20 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 477B621F86CB for ; Wed, 15 Aug 2012 11:34:19 -0700 (PDT) X-AuditID: c1b4fb30-b7fd46d000003161-dd-502beba95772 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 4E.42.12641.9ABEB205; Wed, 15 Aug 2012 20:34:18 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.21]) by esessmw0247.eemea.ericsson.se ([153.88.115.93]) with mapi; Wed, 15 Aug 2012 20:34:17 +0200 From: Christer Holmberg To: Roni Even , 'Andy Pepperell' Date: Wed, 15 Aug 2012 20:32:16 +0200 Thread-Topic: SDP and simulcast [was: [clue] Fwd: #11: RTP header extension for Capture ID ] Thread-Index: AQHNexSTBqxOyDWNYESwoigI3L/sZQ== Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585340868366C@ESESSCMS0356.eemea.ericsson.se> References: <068.5ca029063d5e7080dd9f9169d703adcf@trac.tools.ietf.org> <7F2072F1E0DE894DA4B517B93C6A0585340868365E@ESESSCMS0356.eemea.ericsson.se> <005201cd7a62$40e62260$c2b26720$@gmail.com> <502AB7B1.4070506@alum.mit.edu> <003901cd7ac7$22323a10$6696ae30$@gmail.com> <005001cd7ae1$76159a90$6240cfb0$@gmail.com> , <008201cd7b09$c44f0ed0$4ced2c70$@gmail.com> In-Reply-To: <008201cd7b09$c44f0ed0$4ced2c70$@gmail.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrNLMWRmVeSWpSXmKPExsUyM+Jvre6q19oBBrdnM1tM+t3IYrH/1GVm i7/tzA7MHjtn3WX3WLLkJ1MAUxSXTUpqTmZZapG+XQJXRsuCh+wF+xIr/l1axtrAeNi/i5GT Q0LAROLoiR4WCFtM4sK99WwgtpDAKUaJCfPdIOwFjBKbnoV1MXJwsAlYSHT/0wYJiwj4Stzb c5AZxGYWUJb42rCJCcRmEVCVmLRoH9gYYYFIiUWNKxkh6uMktv7eCWXrSez5dR2shlcgXOLA lqlAcS6gVR1sElNWTmAHSXAC7Xr2eh0riM0IdNv3U2uYIJaJS9x6Mp8J4mYBiSV7zjND2KIS Lx//g6oXlbjTvp4Rol5P4sbUKWwQtrbEsoWvmSEWC0qcnPmEZQKj2CwkY2chaZmFpGUWkpYF jCyrGIVzEzNz0svN9VKLMpOLi/Pz9IpTNzECI+jglt8GOxg33Rc7xCjNwaIkzqunut9fSCA9 sSQ1OzW1ILUovqg0J7X4ECMTB6dUA2P20+ct+1y8BKT1o8s+i388x3DcMzom57TrtBm1ew/t LzYtn3xiWenieT/K7Req6q3ecm/KpcU+/Tz6GUJu/tXt7q1XD+tfvu4/YdP26a5WXSx3pyhd fbRd+WNulWHX3Q+TfBP7/q98xaclVV27In2BAHfuyrsJh5nu5QntbulqN3LdE7HbuVmJpTgj 0VCLuag4EQDJ/pb1bgIAAA== Cc: "clue@ietf.org" Subject: [clue] SDP and simulcast [was: Fwd: #11: RTP header extension for Capture ID ] 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, 15 Aug 2012 18:34:21 -0000 FYI, There is now a new draft for simulcast: http://tools.ietf.org/id/draft-westerlund-avtcore-rtp-simulcast-01.txt Regards, Christer ________________________________ From: clue-bounces@ietf.org [clue-bounces@ietf.org] On Behalf Of Roni Even = [ron.even.tlv@gmail.com] Sent: Wednesday, August 15, 2012 8:16 PM To: 'Andy Pepperell' Cc: clue@ietf.org Subject: Re: [clue] Fwd: #11: RTP header extension for Capture ID Andy, The CLUE charter is not to replace SDP, so negotiating simulcast is the req= uirement you want to address. There are two questions: 1. Should CLUE address it if there is no current SDP way (only docume= nt I found was draft-westerlund-avtcore-multistream-and-simulcast-00 expire= d on January) 2. Does it require having the consumer define the capture ID. As for pre-declaration of SSRC , I do not see the problem in the topologies= that use mixer based SSRCs which is very common use today. Saying that the= re is a big number is not correct when the mixer/MCU creates the advertisem= ent to each participant. I do not have any proof for such case. I agree = that when the mixer will relay the SSRCs the number can be large and there = is no need to define the SSRCs in the SDP from the mixer since the mixer wi= ll not even know all the SSRCs from all the sources. What we presented is t= o have the SSRC for the static case and send a dynamic change with the medi= a (if we use RTP header extension). The mixer knows which topology it is us= ing and can decide if to use static mapping and/or dynamic mapping. For mos= t MCUs today static mapping will be enough and there will be no need to sen= d the RTP header extension at all. Roni From: Andy Pepperell [mailto:apeppere@gmail.com] Sent: 15 August, 2012 5:15 PM To: Roni Even Cc: Roni even; clue@ietf.org Subject: Re: [clue] Fwd: #11: RTP header extension for Capture ID Hi Roni, I'm not sure of the validity of needing simulcast defined in SDP before we = can start to think about it in CLUE. The messages and mechanisms as current= ly defined in CLUE give us simulcast functionality without the need for SDP= additions (which wouldn't necessarily be a good fit for CLUE anyway, just = like the pre-declaration of SSRC values doesn't scale all that well to all = CLUE multi-stream use cases). >If you can point me to how to describe simulcast in SDP the issue can be s= olved. As above, I don't believe this is a prerequisite at all for us to be able t= o make progress in CLUE. Or, alternatively, introducing dependencies on suc= h general solutions which may or may not be in the pipeline would seem like= ly only to impede progress on CLUE (IMHO, of course!). Regards, Andy On Wed, Aug 15, 2012 at 1:28 PM, Roni Even > wrote: Hi Andy, I think this is an SDP problem. If you can point me to how to describe simu= lcast in SDP the issue can be solved. If not then we need to solve it for t= he general case and not only for CLUE Roni From: Andy Pepperell [mailto:apeppere@gmail.com] Sent: 15 August, 2012 12:34 PM To: Roni even Cc: Roni Even; clue@ietf.org Subject: Re: [clue] Fwd: #11: RTP header extension for Capture ID Hi Roni, The main complexities I'd see with that approach is the simulcast aspect - = the provider may have the potential to supply, say, 4 different captures bu= t the consumer could (encoding groups permitting) ask for 4 different encod= ings of the same capture or 1 encoding of each capture, and the SSRC / head= er extension ID allocation scheme has to work for all cases. The only way I can see for this to work would be for the provider's adverti= sement to include a header extension ID or SSRC value associated with each = of its encoding groups' constituent potential encodings - that way the cons= umer would know from its own capture instantiation <--> encoding mapping wh= ich ID or SSRC the provider would be using. This has been discussed before = and from what I recall (these aren't necessarily my reasons): - it's seen as advantageous for the consumer to allocate the IDs so that it= can apply some structure to them (e.g. some sort of hardware routing info) - it's maybe also advantageous to decouple the consumer-side multi-stream d= emultiplexing from encoding groups' [potential] encodings (if this latter w= ere subject to further / future modifications, for instance in order to cop= e with some more complex / flexible encoding cases that have been discussed= , we wouldn't necessarily want to have to revisit the RTP multi-stream hand= ling). Is this kind of in line with what you were thinking, or did you some other = thoughts on where / how the provider would allocate and indicate these? Regards, Andy On Wed, Aug 15, 2012 at 10:48 AM, Roni even > wrote: Hi Andy, Yes the provider should allocate the ID since he is defining the captures a= nd the SSRCs Roni ________________________________ From: clue-bounces@ietf.org [clue-bounces@iet= f.org] on behalf of Andy Pepperell [apeppere@= gmail.com] Sent: Wednesday, August 15, 2012 11:57 To: Roni Even Cc: clue@ietf.org Subject: Re: [clue] Fwd: #11: RTP header extension for Capture ID Hi Roni, I'm not sure I understand the point - are you asking why the consumer is as= signing the IDs rather than the provider? or, taking it further, are you pr= oposing that the provider allocate the IDs? Andy On Wed, Aug 15, 2012 at 10:19 AM, Roni Even > wrote: Andy, I fail to understand why the consumer needs to define the mapping ID for a = mapping done by the provider Roni From: clue-bounces@ietf.org [mailto:clue-boun= ces@ietf.org] On Behalf Of Andy Pepperell Sent: 15 August, 2012 9:48 AM To: christer.holmberg@ericsson.com Cc: clue@ietf.org Subject: Re: [clue] Fwd: #11: RTP header extension for Capture ID Hi Christer, >Is there a reason why we can't use the SSRC? Or, can multiple captures sha= re the same SSRC? I don't think I'm disagreeing here with anything that Roni or Paul are sayi= ng, but was thinking that the phrase "use the SSRC" potentially covers a fe= w different cases... - If we're talking about declaring SSRC values in advance in SDP, this is l= ikely to cause scalability issues with CLUE (more so than with, say, curren= t webrtc implementations) because of the potential for a large number of CL= UE streams in MCU cases. - The current RTP header extension proposal involves the consumer telling t= he provider an ID to use in the RTP header extension for each instantiated = capture, which the consumer can then use to separate the multiple capture i= nstantiations when they are received. It would clearly be reasonably straig= htforward for the CLUE consumer stream choice message to instead indicate a= n SSRC here instead of an ID to be put in an RTP header extension, but as P= aul points out, this means that the consumer then loses the ability to dist= inguish stream changes within a switched capture (modulo CSRC usage). >[Paul] >For instance, for the switched case it would then be necessary to assign a= n ssrc for the switched capture... Agreed, though I think the SSRC assignment would have to be on the basis of= the switched capture's *instantiation* rather than the switched capture it= self - with the simulcast aspects of CLUE as currently defined, mappings ca= n't be on the basis of just capture IDs as a consumer may request multiple = instantiations of the same capture from the provider, and so a simple SSRC = <--> capture ID mapping would not be sufficient. Regards, Andy On Tue, Aug 14, 2012 at 9:40 PM, Paul Kyzivat > wrote: On 8/14/12 5:17 PM, Roni Even wrote: Hi Christer, This works for static SSRCs when the mixer uses its own SSRC. The problem i= s in the switching case when using the source SSRC. An example is when a thre= e camera system has two captures to send to a two monitor system. The three camera system may send first the left and center camera but when switching to center and right camera the center camera will switch from right capture to left capture. This was discussed in my presentation in CLUE about mapping RTP streams. AFAIK it *could* work using SSRC. But then there are different constraints = on how RTP is used. For instance, for the switched case it would then be necessary to assign an= ssrc for the switched capture, and indicate the source via csrc. It also then means that if a source is moved from one switched capture to a= different one, the recipient won't know that it is the *same* RTP stream. = And that affects the number of iframes transmitted, etc. tradeoffs! Thanks, Paul Roni -----Original Message----- From: clue-bounces@ietf.org [mailto:clue-boun= ces@ietf.org] On Behalf Of Christer Holmberg Sent: 14 August, 2012 9:38 PM To: Mary Barnes; CLUE Subject: Re: [clue] Fwd: #11: RTP header extension for Capture ID Hi, A silly question: Is there a reason why we can't use the SSRC? Or, can multiple captures shar= e the same SSRC? Regards, Christer ________________________________ From: clue-bounces@ietf.org [clue-bounces@iet= f.org] On Behalf Of Mary Barnes [mary.ietf.barnes@gmail.com] Sent: Monday, August 13, 2012 10:37 PM To: CLUE Subject: [clue] Fwd: #11: RTP header extension for Capture ID Hi all, I have updated/closed the issues as discussed at the meeting (and captured in the minutes): http://www.ietf.org/proceedings/84/minutes/minutes-84-clu= e I decided to open a ticket to track this issue since it does require some mailing list discussion and hopefully, this will trigger that. The action items from the meeting that are not related to issues are update= s to documents - i.e., new data model document and adding telemedical use cas= e to the WG use case document. Mary. ---------- Forwarded message ---------- From: clue issue tracker >> Date: Mon, Aug 13, 2012 at 2:33 PM Subject: [clue] #11: RTP header extension for Capture ID To: clue-chairs@tools.ietf.org>, mary.ietf.barnes@gmail.com> Cc: clue@ietf.org> #11: RTP header extension for Capture ID Is an RTP header extension needed to transport a capture ID (per draft- lennox-clue-rtp-usage-04)? -- -----------------------------------+--------------------------- Reporter: mary.ietf.barnes@. | Owner:= clue-chairs@. Type: defect | Status: new Priority: major | Milestone: milestone1 Component: charter | Version: 1.0 Severity: Candidate WG Document | Keywords: RTP -----------------------------------+--------------------------- Ticket URL: 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 paul.witty@silverflare.com Thu Aug 16 06:45: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 8F5D821F84C9 for ; Thu, 16 Aug 2012 06:45:58 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KyYkpHJ5AauE for ; Thu, 16 Aug 2012 06:45:57 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6587221F84A6 for ; Thu, 16 Aug 2012 06:45:57 -0700 (PDT) Received: by eaai11 with SMTP id i11so809455eaa.31 for ; Thu, 16 Aug 2012 06:45:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=2Bnl4UMLAaaqd9HkHXrzqSKWXUOUUzV2m/cqCjCYaz8=; b=kjP5T1rYS1o1FPgsmHUv7YZn//z50R1ZdtKdRcqeal7A831wAIQjj6tO4FgdZ6msKy hYvbhBK7yMl9XkMl/BjyZ67MtUJdhOC8qGXNcOWXfzU4ztHiwOB97w6jCVErml9xBFlZ Xhdl/CYtA3UXUSZNl5kKhIQyFc5N48oMOj9IjlrCQ4Yij4pg2T43/fjUjGOGracBfhfC xPwlZHmvZed6wA/9uXv5x9DMALTAotMBzRwCWHYPsa2H3lBxwKRtJonFWVt/62nkQDlg v1Jka+Kc5YBZ8a6rdXJuJmVske4sXvZ0/SLi5UwnnGRSSQjL8KBq/3C80mIRhlOJRsFx fw/g== Received: by 10.14.211.3 with SMTP id v3mr1613696eeo.43.1345124756331; Thu, 16 Aug 2012 06:45:56 -0700 (PDT) Received: from [10.1.2.227] (82-70-15-70.dsl.in-addr.zen.co.uk. [82.70.15.70]) by mx.google.com with ESMTPS id e7sm12332167eep.2.2012.08.16.06.45.55 (version=SSLv3 cipher=OTHER); Thu, 16 Aug 2012 06:45:55 -0700 (PDT) Message-ID: <502CF926.6030202@silverflare.com> Date: Thu, 16 Aug 2012 14:44:06 +0100 From: Paul Witty User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120723 Thunderbird/14.0 MIME-Version: 1.0 To: clue@ietf.org References: <068.5ca029063d5e7080dd9f9169d703adcf@trac.tools.ietf.org> <7F2072F1E0DE894DA4B517B93C6A0585340868365E@ESESSCMS0356.eemea.ericsson.se> <005201cd7a62$40e62260$c2b26720$@gmail.com> <502AB7B1.4070506@alum.mit.edu> <003901cd7ac7$22323a10$6696ae30$@gmail.com> <502BCDF8.4020301@alum.mit.edu> <502BD049.5090209@silverflare.com> <502BE2FB.7040407@alum.mit.edu> In-Reply-To: <502BE2FB.7040407@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQmsqnCINX+iMBzo8H+rDtpOnO3HFIXVPHYRMKKc8Psgwly7pxPPjP8QSZdDV+V+Xx6edh44 Subject: Re: [clue] Fwd: #11: RTP header extension for Capture ID 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, 16 Aug 2012 13:45:58 -0000 On 15/08/12 18:57, Paul Kyzivat wrote: > On 8/15/12 12:37 PM, Paul Witty wrote: >> Each encoded media stream must have a distinct SSRC. If a source is sent >> in two separate requested captures (i.e. simulcasting of two resolutions >> by a transcoding middle box), then the two encodings of the same capture >> will have distinct SSRCs, but the SSRC of the original encoding of the >> source as a CSRC. > > That seems to be in conflict with wanting to send the source SSRC for > switched captures. If there is a middle box doing a transcode of a stream (for whatever reason, such as resolution / codec / bandwidth / packet loss resilience), we shouldn't preserve SSRC, because the SSRC uniquely identifies a media sender. By including the SSRC of the original stream in the transcoded stream as a CSRC, we can then forward on RTCP information, such as SDES, from the original sender to all receivers of the transcoded stream, to ensure no information is lost. We still send the source SSRC (as a CSRC), but make it clear that this is a transcode, and therefore properties such as encryption state which are tied to an SSRC are not incorrectly applied to the transcoded stream. > > But that is also an arrangement that suggests the SSRC could be used > to identify the capture+encoding. Potentially yes, by the consumer declaring the mapping of SSRC to media stream properties (which capture is being shown, what are the bounds on resolution/bandwidth etc). However, this requires everyone along the chain to agree on the SSRC for a particular stream, otherwise we have to rewrite the SSRC at some point. In the switched multipoint case, this would mean that the switching point would have to rewrite the SSRC of an incoming media stream before forwarding it on, as it would be sending out a stream with a constant SSRC, consisting of the un-transcoded media from multiple sources with different SSRCs, suggesting falsely that the outgoing media stream is being generated as one continuous stream. > >> If we want to send the same encoding over two >> requested captures (i.e. requesting both a single stream of loudest >> speaker, and left/centre/right streams from a single endpoint, where the >> former will always be one of the latter), we can use multiple instances >> of the RTP extension in the RTP header, one for each of the requested >> captures. > > That is a situation where using the SSRC to identify the > capture+encoding has a major cost in bandwidth. Indeed; we can't use the same SSRC for two streams over the same RTP session, so the only way to send the same media to two captures would be to send it twice. -- Paul W From pkyzivat@alum.mit.edu Thu Aug 16 08:14: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 CCF7F21F85A0 for ; Thu, 16 Aug 2012 08:14:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.219 X-Spam-Level: X-Spam-Status: No, score=-1.219 tagged_above=-999 required=5 tests=[AWL=-0.782, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DK3hYFx0ytYL for ; Thu, 16 Aug 2012 08:14:31 -0700 (PDT) Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:24]) by ietfa.amsl.com (Postfix) with ESMTP id 216E821F8582 for ; Thu, 16 Aug 2012 08:14:30 -0700 (PDT) Received: from omta18.westchester.pa.mail.comcast.net ([76.96.62.90]) by qmta02.westchester.pa.mail.comcast.net with comcast id nPc61j0031wpRvQ51TEZAK; Thu, 16 Aug 2012 15:14:33 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta18.westchester.pa.mail.comcast.net with comcast id nTNS1j0173ZTu2S3eTNTlj; Thu, 16 Aug 2012 15:22:27 +0000 Message-ID: <502D0E55.2090304@alum.mit.edu> Date: Thu, 16 Aug 2012 11:14:29 -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: <068.5ca029063d5e7080dd9f9169d703adcf@trac.tools.ietf.org> <7F2072F1E0DE894DA4B517B93C6A0585340868365E@ESESSCMS0356.eemea.ericsson.se> <005201cd7a62$40e62260$c2b26720$@gmail.com> <502AB7B1.4070506@alum.mit.edu> <003901cd7ac7$22323a10$6696ae30$@gmail.com> <502BCDF8.4020301@alum.mit.edu> <502BD049.5090209@silverflare.com> <502BE2FB.7040407@alum.mit.edu> <502CF926.6030202@silverflare.com> In-Reply-To: <502CF926.6030202@silverflare.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] Fwd: #11: RTP header extension for Capture ID 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, 16 Aug 2012 15:14:31 -0000 On 8/16/12 9:44 AM, Paul Witty wrote: > On 15/08/12 18:57, Paul Kyzivat wrote: >> On 8/15/12 12:37 PM, Paul Witty wrote: >>> Each encoded media stream must have a distinct SSRC. If a source is sent >>> in two separate requested captures (i.e. simulcasting of two resolutions >>> by a transcoding middle box), then the two encodings of the same capture >>> will have distinct SSRCs, but the SSRC of the original encoding of the >>> source as a CSRC. >> >> That seems to be in conflict with wanting to send the source SSRC for >> switched captures. > If there is a middle box doing a transcode of a stream (for whatever > reason, such as resolution / codec / bandwidth / packet loss > resilience), we shouldn't preserve SSRC, because the SSRC uniquely > identifies a media sender. I'm no expert, but it is my impression that its permissible to have a transcoder that preserves the SSRC. Can someone who is an expert confirm or deny this? > By including the SSRC of the original stream > in the transcoded stream as a CSRC, we can then forward on RTCP > information, such as SDES, from the original sender to all receivers of > the transcoded stream, to ensure no information is lost. We still send > the source SSRC (as a CSRC), but make it clear that this is a transcode, > and therefore properties such as encryption state which are tied to an > SSRC are not incorrectly applied to the transcoded stream. >> >> But that is also an arrangement that suggests the SSRC could be used >> to identify the capture+encoding. > Potentially yes, by the consumer declaring the mapping of SSRC to media > stream properties (which capture is being shown, what are the bounds on > resolution/bandwidth etc). However, this requires everyone along the > chain to agree on the SSRC for a particular stream, otherwise we have to > rewrite the SSRC at some point. I wasn't thinking of the *consumer* declaring this. I was thinking that this would be part of the advertisement. But it does require some changes since the SSRC would need to be associated with the capture+encoding. I haven't thought through how that might be accomplished. > In the switched multipoint case, this would mean that the switching > point would have to rewrite the SSRC of an incoming media stream before > forwarding it on, as it would be sending out a stream with a constant > SSRC, consisting of the un-transcoded media from multiple sources with > different SSRCs, suggesting falsely that the outgoing media stream is > being generated as one continuous stream. I don't understand enough of RTP to know if that is valid. >>> If we want to send the same encoding over two >>> requested captures (i.e. requesting both a single stream of loudest >>> speaker, and left/centre/right streams from a single endpoint, where the >>> former will always be one of the latter), we can use multiple instances >>> of the RTP extension in the RTP header, one for each of the requested >>> captures. >> >> That is a situation where using the SSRC to identify the >> capture+encoding has a major cost in bandwidth. > Indeed; we can't use the same SSRC for two streams over the same RTP > session, so the only way to send the same media to two captures would be > to send it twice. Thanks, Paul From ron.even.tlv@gmail.com Thu Aug 16 08:36: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 8CF7221F8616 for ; Thu, 16 Aug 2012 08:36:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.503 X-Spam-Level: X-Spam-Status: No, score=-3.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S0fJED7-fmMP for ; Thu, 16 Aug 2012 08:36:20 -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 7548721F8610 for ; Thu, 16 Aug 2012 08:36:19 -0700 (PDT) Received: by wicr5 with SMTP id r5so634866wic.13 for ; Thu, 16 Aug 2012 08:36:18 -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=JUy6jQw6THg67WlupO/wtgFzaxoH8E2t+EpToOtc5GU=; b=x7t9KQGsqHb7rQ6RwNo21mHwqLD11Uvs1k1va3zD8TlKzCXUo8jy2NnsyDaaTBTI47 DMqDHVdriCfUqN6N31WQ1fRoD4bsiM8fMYUvUEE718NqxDi/bLThPlg/rDdBDvV7Vg2h mEUQozkjfBgkjhT73R75txvcDGOzDYsfKZCQ3VynUgUGGlRZ5PMkHgLQJXpnPFmCF2zp X/83waBBraft+HsIm7dVPJLr/yYe55IIJI8vBQrL5B74JiB0t7yHRlm2YdvM348ZNfPu ASr+x3iI5oUHe5YfWZZC09CUaB2TvJ/FKwXkwSRgbMCCi0RMPgTtQueq8HWGyTFYWkCF I3mg== Received: by 10.180.103.136 with SMTP id fw8mr4094984wib.20.1345131378544; Thu, 16 Aug 2012 08:36:18 -0700 (PDT) Received: from RoniE (bzq-79-176-199-111.red.bezeqint.net. [79.176.199.111]) by mx.google.com with ESMTPS id o2sm6579735wiz.11.2012.08.16.08.36.16 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 16 Aug 2012 08:36:17 -0700 (PDT) From: "Roni Even" To: "'Paul Kyzivat'" , References: <068.5ca029063d5e7080dd9f9169d703adcf@trac.tools.ietf.org> <7F2072F1E0DE894DA4B517B93C6A0585340868365E@ESESSCMS0356.eemea.ericsson.se> <005201cd7a62$40e62260$c2b26720$@gmail.com> <502AB7B1.4070506@alum.mit.edu> <003901cd7ac7$22323a10$6696ae30$@gmail.com> <502BCDF8.4020301@alum.mit.edu> <502BD049.5090209@silverflare.com> <502BE2FB.7040407@alum.mit.edu> <502CF926.6030202@silverflare.com> <502D0E55.2090304@alum.mit.edu> In-Reply-To: <502D0E55.2090304@alum.mit.edu> Date: Thu, 16 Aug 2012 18:35:06 +0200 Message-ID: <010801cd7bcd$19eb5e20$4dc21a60$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFM/VlsLWUUBwuvWjT5seMrvYeAmQJvL0GbAjiJEHMBkpDbuQJNqn6UAo7Cq90BwIuCfgHI6I13Ajy/Ug8BBkj53QHS+YytAhGIVIgBy+pXiAG1CtMAAf2tgMCXg2wPQA== Content-Language: en-us Subject: Re: [clue] Fwd: #11: RTP header extension for Capture ID 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, 16 Aug 2012 15:36:20 -0000 Paul, Look at my rtp mapping draft, an intermediary may keep the original SSRC from the source or create an SSRC and have the source SSRC in the CSRC field. A transcoder will usually use his own SSRC since it is a different stream from a different source (the transcoder) Roni -----Original Message----- From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: 16 August, 2012 5:14 PM To: clue@ietf.org Subject: Re: [clue] Fwd: #11: RTP header extension for Capture ID On 8/16/12 9:44 AM, Paul Witty wrote: > On 15/08/12 18:57, Paul Kyzivat wrote: >> On 8/15/12 12:37 PM, Paul Witty wrote: >>> Each encoded media stream must have a distinct SSRC. If a source is >>> sent in two separate requested captures (i.e. simulcasting of two >>> resolutions by a transcoding middle box), then the two encodings of >>> the same capture will have distinct SSRCs, but the SSRC of the >>> original encoding of the source as a CSRC. >> >> That seems to be in conflict with wanting to send the source SSRC for >> switched captures. > If there is a middle box doing a transcode of a stream (for whatever > reason, such as resolution / codec / bandwidth / packet loss > resilience), we shouldn't preserve SSRC, because the SSRC uniquely > identifies a media sender. I'm no expert, but it is my impression that its permissible to have a transcoder that preserves the SSRC. Can someone who is an expert confirm or deny this? > By including the SSRC of the original stream in the transcoded stream > as a CSRC, we can then forward on RTCP information, such as SDES, from > the original sender to all receivers of the transcoded stream, to > ensure no information is lost. We still send the source SSRC (as a > CSRC), but make it clear that this is a transcode, and therefore > properties such as encryption state which are tied to an SSRC are not > incorrectly applied to the transcoded stream. >> >> But that is also an arrangement that suggests the SSRC could be used >> to identify the capture+encoding. > Potentially yes, by the consumer declaring the mapping of SSRC to > media stream properties (which capture is being shown, what are the > bounds on resolution/bandwidth etc). However, this requires everyone > along the chain to agree on the SSRC for a particular stream, > otherwise we have to rewrite the SSRC at some point. I wasn't thinking of the *consumer* declaring this. I was thinking that this would be part of the advertisement. But it does require some changes since the SSRC would need to be associated with the capture+encoding. I haven't thought through how that might be accomplished. > In the switched multipoint case, this would mean that the switching > point would have to rewrite the SSRC of an incoming media stream > before forwarding it on, as it would be sending out a stream with a > constant SSRC, consisting of the un-transcoded media from multiple > sources with different SSRCs, suggesting falsely that the outgoing > media stream is being generated as one continuous stream. I don't understand enough of RTP to know if that is valid. >>> If we want to send the same encoding over two requested captures >>> (i.e. requesting both a single stream of loudest speaker, and >>> left/centre/right streams from a single endpoint, where the former >>> will always be one of the latter), we can use multiple instances of >>> the RTP extension in the RTP header, one for each of the requested >>> captures. >> >> That is a situation where using the SSRC to identify the >> capture+encoding has a major cost in bandwidth. > Indeed; we can't use the same SSRC for two streams over the same RTP > session, so the only way to send the same media to two captures would > be to send it twice. Thanks, Paul _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue From paul.witty@silverflare.com Thu Aug 16 11:31: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 434F121F8609 for ; Thu, 16 Aug 2012 11:31:09 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y4qb6S7lJsrc for ; Thu, 16 Aug 2012 11:31:08 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 684B021F85D0 for ; Thu, 16 Aug 2012 11:31:08 -0700 (PDT) Received: by eekb45 with SMTP id b45so899590eek.31 for ; Thu, 16 Aug 2012 11:31:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=Up31RHCiNq1VKe86UCCNi+d7EJW8UH8TO2vasp+Q+gM=; b=Yn6udeC/PCNJ2BdvLv5zny6Kwva9eO8vJN4LJtrQwRKgHDLESULj6Hwa7UAIu2rc0t sViqHBPM5pN1HG0LuimUILdbZ7mt7Bo7fzI3mZbkHhhgG6yj6yQz1rm4KroAVjVLiZ4c fMic3GZ/tExekGw9wGRdjOqLyGkXraUxwokCTkhle+y3DRi13MeIO+86fyaQ01cny60l srTLt0cyzoDxw61yZ42I7z56u2A4EsQ9A0ksF/Wbf7KH1ly6zsNmYpp4IzU6b+zCSElQ cZyyqjAueW8Uq8beyLb/LdbIGzh/SPD8MIl8GfcwZLJh+qPokrQxtyOhk4jXiqVTCJYW rbNg== Received: by 10.14.223.9 with SMTP id u9mr2963517eep.10.1345141867483; Thu, 16 Aug 2012 11:31:07 -0700 (PDT) Received: from [10.1.2.227] (82-70-15-70.dsl.in-addr.zen.co.uk. [82.70.15.70]) by mx.google.com with ESMTPS id z3sm11745718eel.15.2012.08.16.11.31.06 (version=SSLv3 cipher=OTHER); Thu, 16 Aug 2012 11:31:06 -0700 (PDT) Message-ID: <502D3BFD.1080904@silverflare.com> Date: Thu, 16 Aug 2012 19:29:17 +0100 From: Paul Witty User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120723 Thunderbird/14.0 MIME-Version: 1.0 To: clue@ietf.org References: <068.5ca029063d5e7080dd9f9169d703adcf@trac.tools.ietf.org> <7F2072F1E0DE894DA4B517B93C6A0585340868365E@ESESSCMS0356.eemea.ericsson.se> <005201cd7a62$40e62260$c2b26720$@gmail.com> <502AB7B1.4070506@alum.mit.edu> <003901cd7ac7$22323a10$6696ae30$@gmail.com> <502BCDF8.4020301@alum.mit.edu> <502BD049.5090209@silverflare.com> <502BE2FB.7040407@alum.mit.edu> <502CF926.6030202@silverflare.com> <502D0E55.2090304@alum.mit.edu> <010801cd7bcd$19eb5e20$4dc21a60$@gmail.com> In-Reply-To: <010801cd7bcd$19eb5e20$4dc21a60$@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQlKdZNAs5WkXvvpgfrRDXpAiH+aJaZc6UzA7HYP2fRiQQduC0oak0llAK9MPzGW5Im6nuX5 Subject: Re: [clue] Fwd: #11: RTP header extension for Capture ID 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, 16 Aug 2012 18:31:09 -0000 On 16/08/12 17:35, Roni Even wrote: > Paul, > Look at my rtp mapping draft, an intermediary may keep the original SSRC > from the source or create an SSRC and have the source SSRC in the CSRC > field. Keeping the original SSRC should be preferred where possible - rewriting SSRCs results in the need to reauthenticate SRTP packets, as well as rewrite RTCP sender reports & SDES. Rewriting two distinct streams to the same SSRC should definitely be avoided in my opinion, to ensure that within a single SSRC the sequence numbers, timestamps, encryption parameters all stay consistent, as well as other codec-specific features such as long term reference frames. > A transcoder will usually use his own SSRC since it is a different stream > from a different source (the transcoder) Agreed. I'd say should this should be upgraded from usually to always, to ensure there aren't two different streams (with independent sequence number, timestamp, encryption domains) with the same SSRC existing anywhere in the system. -- Paul W From paul.witty@silverflare.com Thu Aug 16 11:38: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 8C3BF21F8564 for ; Thu, 16 Aug 2012 11:38:57 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YYl3CVArvjY2 for ; Thu, 16 Aug 2012 11:38:57 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 85D2E21F8532 for ; Thu, 16 Aug 2012 11:38:56 -0700 (PDT) Received: by eekb45 with SMTP id b45so901517eek.31 for ; Thu, 16 Aug 2012 11:38:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=4Ru6sh/OAZbH0KmsfyFtmafVK1VpOpjMLTtjodO4C4I=; b=Yi1GgOtc67pMVdJYNEbl0fqxxjBevQgWFSOtSHUOH+VZ4XzQ0vKxycsYfRBsdxeDf5 rdcOuykd+4oZ1+dF/G0sdLx78EnovTOyzKDl6mNp+OeqAHUGw4KZ8J/Bh1+ZWdDVmXKp 1IJN/Xg7xUF0yHtSqMS/eF6/9BoChRFQ3UvieNKyoVSm8DbpitJ7LU4vlkIeMCgRAz45 xgplWtYvHcUm2yGLt87xYXLl6KMMQ9fhphp3pphgfwjYxPVW78S3GWV3cUxFbucDufs1 oU/U7Tl0V1Kslp48xXzJpTSwl8tEYnyYNjCcIiQU/j19ogvgB7T6xHVsekzi3NjN4vrZ setQ== Received: by 10.14.175.8 with SMTP id y8mr2985122eel.8.1345142335496; Thu, 16 Aug 2012 11:38:55 -0700 (PDT) Received: from [10.1.2.227] (82-70-15-70.dsl.in-addr.zen.co.uk. [82.70.15.70]) by mx.google.com with ESMTPS id 45sm14134520eeb.8.2012.08.16.11.38.54 (version=SSLv3 cipher=OTHER); Thu, 16 Aug 2012 11:38:54 -0700 (PDT) Message-ID: <502D3DD1.9050709@silverflare.com> Date: Thu, 16 Aug 2012 19:37:05 +0100 From: Paul Witty User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120723 Thunderbird/14.0 MIME-Version: 1.0 To: clue@ietf.org References: <068.5ca029063d5e7080dd9f9169d703adcf@trac.tools.ietf.org> <7F2072F1E0DE894DA4B517B93C6A0585340868365E@ESESSCMS0356.eemea.ericsson.se> <005201cd7a62$40e62260$c2b26720$@gmail.com> <502AB7B1.4070506@alum.mit.edu> <003901cd7ac7$22323a10$6696ae30$@gmail.com> <502BCDF8.4020301@alum.mit.edu> <502BD049.5090209@silverflare.com> <502BE2FB.7040407@alum.mit.edu> <502CF926.6030202@silverflare.com> <502D0E55.2090304@alum.mit.edu> In-Reply-To: <502D0E55.2090304@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQkm4acMTVnpZEkwt3f3kFELGlnlv82Q6q9gMPbVHVczuF+E3Uvs4ixMkBEe9VAiZC2X0MGz Subject: Re: [clue] Fwd: #11: RTP header extension for Capture ID 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, 16 Aug 2012 18:38:57 -0000 On 16/08/12 16:14, Paul Kyzivat wrote: > On 8/16/12 9:44 AM, Paul Witty wrote: >> On 15/08/12 18:57, Paul Kyzivat wrote: >>> On 8/15/12 12:37 PM, Paul Witty wrote: >>>> Each encoded media stream must have a distinct SSRC. If a source is >>>> sent >>>> in two separate requested captures (i.e. simulcasting of two >>>> resolutions >>>> by a transcoding middle box), then the two encodings of the same >>>> capture >>>> will have distinct SSRCs, but the SSRC of the original encoding of the >>>> source as a CSRC. >>> >>> That seems to be in conflict with wanting to send the source SSRC for >>> switched captures. >> If there is a middle box doing a transcode of a stream (for whatever >> reason, such as resolution / codec / bandwidth / packet loss >> resilience), we shouldn't preserve SSRC, because the SSRC uniquely >> identifies a media sender. > > I'm no expert, but it is my impression that its permissible to have a > transcoder that preserves the SSRC. > > Can someone who is an expert confirm or deny this? I'm not an expert either, but I can see that, if there's no possibility of the original stream being seen on the opposite side of the transcoding device, and all the RTCP is terminated at the transcoding device (to prevent sender reports being sent which give incorrect facts about the transcoded stream, and to ensure the original encoder of the media doesn't receive misleading feedback), it would be possible. I can't see why it would be desirable, however. > >> By including the SSRC of the original stream >> in the transcoded stream as a CSRC, we can then forward on RTCP >> information, such as SDES, from the original sender to all receivers of >> the transcoded stream, to ensure no information is lost. We still send >> the source SSRC (as a CSRC), but make it clear that this is a transcode, >> and therefore properties such as encryption state which are tied to an >> SSRC are not incorrectly applied to the transcoded stream. >>> >>> But that is also an arrangement that suggests the SSRC could be used >>> to identify the capture+encoding. >> Potentially yes, by the consumer declaring the mapping of SSRC to media >> stream properties (which capture is being shown, what are the bounds on >> resolution/bandwidth etc). However, this requires everyone along the >> chain to agree on the SSRC for a particular stream, otherwise we have to >> rewrite the SSRC at some point. > > I wasn't thinking of the *consumer* declaring this. > I was thinking that this would be part of the advertisement. > But it does require some changes since the SSRC would need to be > associated with the capture+encoding. I haven't thought through how > that might be accomplished. If the consumer asks for one stream at 720p, and one stream at CIF, it needs to know in advance of receiving the media, and without examining the media (as it may not be capable of decoding), which of the two streams being sent are which. This can't be done in the advertisement, because the provider only offers the ability to do multiple streams, and doesn't know exactly what the consumer will request, and so can't provide enough information in advance for the consumer to know which is which; the consumer has to do some level of saying "this identifier (whether multiplexing ID, or SSRC) matches this request". The identifiers may be pre-allocated by the provider, but the consumer has to either tell the provider for each requested stream what identifier it would like the provider to use, or the provider can, in response to the request, give the consumer the mapping from identifier to requested stream. -- Paul W From iesg-secretary@ietf.org Thu Aug 16 15:21: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 C47C221F8567; Thu, 16 Aug 2012 15:21:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.538 X-Spam-Level: X-Spam-Status: No, score=-102.538 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IrXhpQ6rtHaH; Thu, 16 Aug 2012 15:21:29 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2839621F8582; Thu, 16 Aug 2012 15:21:29 -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.33 Message-ID: <20120816222129.15925.58799.idtracker@ietfa.amsl.com> Date: Thu, 16 Aug 2012 15:21:29 -0700 Cc: clue@ietf.org Subject: [clue] CLUE WG Interim Meeting, Wednesday and Thursday, September 19-20, 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, 16 Aug 2012 22:21:30 -0000 Hi Folks, A face-to-face interim meeting is being scheduled for the CLUE WG. Date: Sept. 19-20, 2012 Location: Cisco Building 30 =E2=80=93 Globalization Conf Room 707 East Tasman Dr (near corner of Alder)**** Milpitas, CA 95035 Other details (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 csp@csperkins.org Fri Aug 17 04: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 3B1DF21F8508 for ; Fri, 17 Aug 2012 04:51: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=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8sXcdQIAZXFN for ; Fri, 17 Aug 2012 04:51:08 -0700 (PDT) Received: from lon1-msapost-2.mail.demon.net (lon1-msapost-2.mail.demon.net [195.173.77.181]) by ietfa.amsl.com (Postfix) with ESMTP id 53D1621F8505 for ; Fri, 17 Aug 2012 04:51:08 -0700 (PDT) Received: from [193.184.126.114] (helo=[10.0.6.194]) by lon1-post-2.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1T2L51-0001PU-aJ; Fri, 17 Aug 2012 11:51:07 +0000 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Colin Perkins In-Reply-To: <502D0E55.2090304@alum.mit.edu> Date: Fri, 17 Aug 2012 14:51:04 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <7E3F4436-71A7-4333-ABB5-F27A4910BF27@csperkins.org> References: <068.5ca029063d5e7080dd9f9169d703adcf@trac.tools.ietf.org> <7F2072F1E0DE894DA4B517B93C6A0585340868365E@ESESSCMS0356.eemea.ericsson.se> <005201cd7a62$40e62260$c2b26720$@gmail.com> <502AB7B1.4070506@alum.mit.edu> <003901cd7ac7$22323a10$6696ae30$@gmail.com> <502BCDF8.4020301@alum.mit.edu> <502BD049.5090209@silverflare.com> <502BE2FB.7040407@alum.mit.edu> <502CF926.6030202@silverflare.com> <502D0E55.2090304@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1278) Cc: clue@ietf.org Subject: Re: [clue] #11: RTP header extension for Capture ID 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, 17 Aug 2012 11:51:09 -0000 On 16 Aug 2012, at 18:14, Paul Kyzivat wrote: > On 8/16/12 9:44 AM, Paul Witty wrote: >> On 15/08/12 18:57, Paul Kyzivat wrote: >>> On 8/15/12 12:37 PM, Paul Witty wrote: >>>> Each encoded media stream must have a distinct SSRC. If a source is = sent >>>> in two separate requested captures (i.e. simulcasting of two = resolutions >>>> by a transcoding middle box), then the two encodings of the same = capture >>>> will have distinct SSRCs, but the SSRC of the original encoding of = the >>>> source as a CSRC. >>>=20 >>> That seems to be in conflict with wanting to send the source SSRC = for >>> switched captures. >> If there is a middle box doing a transcode of a stream (for whatever >> reason, such as resolution / codec / bandwidth / packet loss >> resilience), we shouldn't preserve SSRC, because the SSRC uniquely >> identifies a media sender. >=20 > I'm no expert, but it is my impression that its permissible to have a = transcoder that preserves the SSRC. >=20 > Can someone who is an expert confirm or deny this? You could implement the transcoder as two back-to-back RTP endpoints and = so two separate RTP sessions, where the SSRC used by the transcoder just = happens to be the same in each session.=20 Alternatively, you could implement the transcoder as an RFC 3550-style = translator. That could maintain the SSRC of the transcoded stream, but = would need to rewrite RTCP to match the transcoding operation [RFC3550 = section 7.2] since there would be a common RTP session across the RTP = translator. --=20 Colin Perkins http://csperkins.org/ From pkyzivat@alum.mit.edu Fri Aug 17 07:47: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 4FDC921F8605 for ; Fri, 17 Aug 2012 07:47:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.295 X-Spam-Level: X-Spam-Status: No, score=-2.295 tagged_above=-999 required=5 tests=[AWL=0.304, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ocJefCGOKGJS for ; Fri, 17 Aug 2012 07:47:07 -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 9FB7D21F8602 for ; Fri, 17 Aug 2012 07:47:07 -0700 (PDT) Received: from omta05.westchester.pa.mail.comcast.net ([76.96.62.43]) by qmta10.westchester.pa.mail.comcast.net with comcast id nqU01j0010vyq2s5AqnANK; Fri, 17 Aug 2012 14:47:10 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta05.westchester.pa.mail.comcast.net with comcast id nqnL1j00o3ZTu2S3RqnLPM; Fri, 17 Aug 2012 14:47:20 +0000 Message-ID: <502E5969.6080505@alum.mit.edu> Date: Fri, 17 Aug 2012 10:47:05 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Colin Perkins References: <068.5ca029063d5e7080dd9f9169d703adcf@trac.tools.ietf.org> <7F2072F1E0DE894DA4B517B93C6A0585340868365E@ESESSCMS0356.eemea.ericsson.se> <005201cd7a62$40e62260$c2b26720$@gmail.com> <502AB7B1.4070506@alum.mit.edu> <003901cd7ac7$22323a10$6696ae30$@gmail.com> <502BCDF8.4020301@alum.mit.edu> <502BD049.5090209@silverflare.com> <502BE2FB.7040407@alum.mit.edu> <502CF926.6030202@silverflare.com> <502D0E55.2090304@alum.mit.edu> <7E3F4436-71A7-4333-ABB5-F27A4910BF27@csperkins.org> In-Reply-To: <7E3F4436-71A7-4333-ABB5-F27A4910BF27@csperkins.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: clue@ietf.org Subject: Re: [clue] #11: RTP header extension for Capture ID 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, 17 Aug 2012 14:47:08 -0000 On 8/17/12 7:51 AM, Colin Perkins wrote: > On 16 Aug 2012, at 18:14, Paul Kyzivat wrote: >> On 8/16/12 9:44 AM, Paul Witty wrote: >>> On 15/08/12 18:57, Paul Kyzivat wrote: >>>> On 8/15/12 12:37 PM, Paul Witty wrote: >>>>> Each encoded media stream must have a distinct SSRC. If a source is sent >>>>> in two separate requested captures (i.e. simulcasting of two resolutions >>>>> by a transcoding middle box), then the two encodings of the same capture >>>>> will have distinct SSRCs, but the SSRC of the original encoding of the >>>>> source as a CSRC. >>>> >>>> That seems to be in conflict with wanting to send the source SSRC for >>>> switched captures. >>> If there is a middle box doing a transcode of a stream (for whatever >>> reason, such as resolution / codec / bandwidth / packet loss >>> resilience), we shouldn't preserve SSRC, because the SSRC uniquely >>> identifies a media sender. >> >> I'm no expert, but it is my impression that its permissible to have a transcoder that preserves the SSRC. >> >> Can someone who is an expert confirm or deny this? > > > You could implement the transcoder as two back-to-back RTP endpoints and so two separate RTP sessions, where the SSRC used by the transcoder just happens to be the same in each session. > > Alternatively, you could implement the transcoder as an RFC 3550-style translator. That could maintain the SSRC of the transcoded stream, but would need to rewrite RTCP to match the transcoding operation [RFC3550 section 7.2] since there would be a common RTP session across the RTP translator. Thanks Colin! The latter is probably what I was thinking of. I gather this is a fairly mainstream mechanism, rather than being something weird. Thanks, Paul From paul.witty@silverflare.com Fri Aug 17 08:19: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 138A621E8034 for ; Fri, 17 Aug 2012 08:19:16 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5rhlRlQJhO9u for ; Fri, 17 Aug 2012 08:19:15 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4A81921F8517 for ; Fri, 17 Aug 2012 08:19:15 -0700 (PDT) Received: by eaai11 with SMTP id i11so1289337eaa.31 for ; Fri, 17 Aug 2012 08:19:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=o41t8Paxxj12TVMtTQqWLsm5Fhxt7hkTEUJaKwYFJ00=; b=UDn07AdAmyvyZMBsF6+/7OUXQDnz4i6kxyUvw+IP48buRFi7qvNHiAVg2cMZlWaY3I t9CiV5Pul5U+a/BPKWsP4RTmXgWalxuxtwYk4JtubEWGa4Th8bDfihPDQXulSG5fyBU2 CN0SGRnz3G5Fdj3ambnynOOfVXl5dgdB+J2qpj1GYLlyjXEf26kbpFZAfrjDMJmh4Q1t 8GLUz3fO882KZl2RPsC5LQcjg4G3jn5aTHlY57KV1k/UzRPXh6nX5txBo3Ze8WKn8KO6 1CLRbAkpBB0IMpASK/v6oqxO6s4NZIoYEwHrRczGoOno7pWKdUI7/dorM0EiMvsMjd2w GSDA== Received: by 10.14.176.6 with SMTP id a6mr3938211eem.13.1345216754399; Fri, 17 Aug 2012 08:19:14 -0700 (PDT) Received: from [10.1.2.227] (82-70-15-70.dsl.in-addr.zen.co.uk. [82.70.15.70]) by mx.google.com with ESMTPS id k49sm20914801een.4.2012.08.17.08.19.12 (version=SSLv3 cipher=OTHER); Fri, 17 Aug 2012 08:19:13 -0700 (PDT) Message-ID: <502E6082.7000407@silverflare.com> Date: Fri, 17 Aug 2012 16:17:22 +0100 From: Paul Witty User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120723 Thunderbird/14.0 MIME-Version: 1.0 To: clue@ietf.org References: <068.5ca029063d5e7080dd9f9169d703adcf@trac.tools.ietf.org> <7F2072F1E0DE894DA4B517B93C6A0585340868365E@ESESSCMS0356.eemea.ericsson.se> <005201cd7a62$40e62260$c2b26720$@gmail.com> <502AB7B1.4070506@alum.mit.edu> <003901cd7ac7$22323a10$6696ae30$@gmail.com> <502BCDF8.4020301@alum.mit.edu> <502BD049.5090209@silverflare.com> <502BE2FB.7040407@alum.mit.edu> <502CF926.6030202@silverflare.com> <502D0E55.2090304@alum.mit.edu> <7E3F4436-71A7-4333-ABB5-F27A4910BF27@csperkins.org> <502E5969.6080505@alum.mit.edu> In-Reply-To: <502E5969.6080505@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQnGppfyWbdcCTmw2My4VOQYe5/e79NgL+VhXYBN2faH52VDf4CN+R/lMgE1msFdgK5pwnD2 Subject: Re: [clue] #11: RTP header extension for Capture ID 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, 17 Aug 2012 15:19:16 -0000 On 17/08/12 15:47, Paul Kyzivat wrote: > On 8/17/12 7:51 AM, Colin Perkins wrote: >> On 16 Aug 2012, at 18:14, Paul Kyzivat wrote: >>> On 8/16/12 9:44 AM, Paul Witty wrote: >>>> On 15/08/12 18:57, Paul Kyzivat wrote: >>>>> On 8/15/12 12:37 PM, Paul Witty wrote: >>>>>> Each encoded media stream must have a distinct SSRC. If a source >>>>>> is sent >>>>>> in two separate requested captures (i.e. simulcasting of two >>>>>> resolutions >>>>>> by a transcoding middle box), then the two encodings of the same >>>>>> capture >>>>>> will have distinct SSRCs, but the SSRC of the original encoding >>>>>> of the >>>>>> source as a CSRC. >>>>> >>>>> That seems to be in conflict with wanting to send the source SSRC for >>>>> switched captures. >>>> If there is a middle box doing a transcode of a stream (for whatever >>>> reason, such as resolution / codec / bandwidth / packet loss >>>> resilience), we shouldn't preserve SSRC, because the SSRC uniquely >>>> identifies a media sender. >>> >>> I'm no expert, but it is my impression that its permissible to have >>> a transcoder that preserves the SSRC. >>> >>> Can someone who is an expert confirm or deny this? >> >> >> You could implement the transcoder as two back-to-back RTP endpoints >> and so two separate RTP sessions, where the SSRC used by the >> transcoder just happens to be the same in each session. >> >> Alternatively, you could implement the transcoder as an RFC >> 3550-style translator. That could maintain the SSRC of the transcoded >> stream, but would need to rewrite RTCP to match the transcoding >> operation [RFC3550 section 7.2] since there would be a common RTP >> session across the RTP translator. > > Thanks Colin! > > The latter is probably what I was thinking of. I gather this is a > fairly mainstream mechanism, rather than being something weird. > I'm not sure mainstream is the right word; I don't believe I've ever seen an implementation of such. A translator like this wouldn't work if a stream is being transcoded to two simulcasted streams; as at least one of them should have a new SSRC, which to me seems like a good reason that every transcode should be given a new SSRC. -- Paul W From pkyzivat@alum.mit.edu Fri Aug 17 08:28: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 9999811E80A5 for ; Fri, 17 Aug 2012 08:28:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.217 X-Spam-Level: X-Spam-Status: No, score=-1.217 tagged_above=-999 required=5 tests=[AWL=-0.780, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v77TYoN5R311 for ; Fri, 17 Aug 2012 08:28:24 -0700 (PDT) Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:24]) by ietfa.amsl.com (Postfix) with ESMTP id B731021F855E for ; Fri, 17 Aug 2012 08:28:23 -0700 (PDT) Received: from omta19.westchester.pa.mail.comcast.net ([76.96.62.98]) by qmta02.westchester.pa.mail.comcast.net with comcast id nn7P1j00627AodY51rUSlj; Fri, 17 Aug 2012 15:28:26 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta19.westchester.pa.mail.comcast.net with comcast id nrUf1j00a3ZTu2S3frUfPR; Fri, 17 Aug 2012 15:28:39 +0000 Message-ID: <502E6316.30706@alum.mit.edu> Date: Fri, 17 Aug 2012 11:28:22 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: clue@ietf.org References: <068.5ca029063d5e7080dd9f9169d703adcf@trac.tools.ietf.org> <7F2072F1E0DE894DA4B517B93C6A0585340868365E@ESESSCMS0356.eemea.ericsson.se> <005201cd7a62$40e62260$c2b26720$@gmail.com> <502AB7B1.4070506@alum.mit.edu> <003901cd7ac7$22323a10$6696ae30$@gmail.com> <502BCDF8.4020301@alum.mit.edu> <502BD049.5090209@silverflare.com> <502BE2FB.7040407@alum.mit.edu> <502CF926.6030202@silverflare.com> <502D0E55.2090304@alum.mit.edu> <7E3F4436-71A7-4333-ABB5-F27A4910BF27@csperkins.org> <502E5969.6080505@alum.mit.edu> <502E6082.7000407@silverflare.com> In-Reply-To: <502E6082.7000407@silverflare.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] #11: RTP header extension for Capture ID 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, 17 Aug 2012 15:28:24 -0000 I'm going to defer to Colin on this. Thanks, Paul K On 8/17/12 11:17 AM, Paul Witty wrote: > On 17/08/12 15:47, Paul Kyzivat wrote: >> On 8/17/12 7:51 AM, Colin Perkins wrote: >>> On 16 Aug 2012, at 18:14, Paul Kyzivat wrote: >>>> On 8/16/12 9:44 AM, Paul Witty wrote: >>>>> On 15/08/12 18:57, Paul Kyzivat wrote: >>>>>> On 8/15/12 12:37 PM, Paul Witty wrote: >>>>>>> Each encoded media stream must have a distinct SSRC. If a source >>>>>>> is sent >>>>>>> in two separate requested captures (i.e. simulcasting of two >>>>>>> resolutions >>>>>>> by a transcoding middle box), then the two encodings of the same >>>>>>> capture >>>>>>> will have distinct SSRCs, but the SSRC of the original encoding >>>>>>> of the >>>>>>> source as a CSRC. >>>>>> >>>>>> That seems to be in conflict with wanting to send the source SSRC for >>>>>> switched captures. >>>>> If there is a middle box doing a transcode of a stream (for whatever >>>>> reason, such as resolution / codec / bandwidth / packet loss >>>>> resilience), we shouldn't preserve SSRC, because the SSRC uniquely >>>>> identifies a media sender. >>>> >>>> I'm no expert, but it is my impression that its permissible to have >>>> a transcoder that preserves the SSRC. >>>> >>>> Can someone who is an expert confirm or deny this? >>> >>> >>> You could implement the transcoder as two back-to-back RTP endpoints >>> and so two separate RTP sessions, where the SSRC used by the >>> transcoder just happens to be the same in each session. >>> >>> Alternatively, you could implement the transcoder as an RFC >>> 3550-style translator. That could maintain the SSRC of the transcoded >>> stream, but would need to rewrite RTCP to match the transcoding >>> operation [RFC3550 section 7.2] since there would be a common RTP >>> session across the RTP translator. >> >> Thanks Colin! >> >> The latter is probably what I was thinking of. I gather this is a >> fairly mainstream mechanism, rather than being something weird. >> > > I'm not sure mainstream is the right word; I don't believe I've ever > seen an implementation of such. > > A translator like this wouldn't work if a stream is being transcoded to > two simulcasted streams; as at least one of them should have a new SSRC, > which to me seems like a good reason that every transcode should be > given a new SSRC. > From csp@csperkins.org Sun Aug 19 03:10: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 D8B1A21F84FE for ; Sun, 19 Aug 2012 03:10:36 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HG+YSzi2SzYR for ; Sun, 19 Aug 2012 03:10:36 -0700 (PDT) Received: from anchor-msapost-2.mail.demon.net (anchor-msapost-2.mail.demon.net [195.173.77.165]) by ietfa.amsl.com (Postfix) with ESMTP id D7DF721F84F9 for ; Sun, 19 Aug 2012 03:10:35 -0700 (PDT) Received: from [194.86.25.98] (helo=[10.2.1.83]) by anchor-post-2.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1T32So-00010y-lb; Sun, 19 Aug 2012 10:10:34 +0000 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Colin Perkins In-Reply-To: <502E6082.7000407@silverflare.com> Date: Sun, 19 Aug 2012 13:10:32 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <75B28CE0-86C9-4930-BE39-7D66044EB251@csperkins.org> References: <068.5ca029063d5e7080dd9f9169d703adcf@trac.tools.ietf.org> <7F2072F1E0DE894DA4B517B93C6A0585340868365E@ESESSCMS0356.eemea.ericsson.se> <005201cd7a62$40e62260$c2b26720$@gmail.com> <502AB7B1.4070506@alum.mit.edu> <003901cd7ac7$22323a10$6696ae30$@gmail.com> <502BCDF8.4020301@alum.mit.edu> <502BD049.5090209@silverflare.com> <502BE2FB.7040407@alum.mit.edu> <502CF926.6030202@silverflare.com> <502D0E55.2090304@alum.mit.edu> <7E3F4436-71A7-4333-ABB5-F27A4910BF27@csperkins.org> <502E5969.6080505@alum.mit.edu> <502E6082.7000407@silverflare.com> To: Paul Witty X-Mailer: Apple Mail (2.1278) Cc: clue@ietf.org Subject: Re: [clue] #11: RTP header extension for Capture ID 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: Sun, 19 Aug 2012 10:10:37 -0000 On 17 Aug 2012, at 18:17, Paul Witty wrote: > On 17/08/12 15:47, Paul Kyzivat wrote: >> On 8/17/12 7:51 AM, Colin Perkins wrote: >>> On 16 Aug 2012, at 18:14, Paul Kyzivat wrote: >>>> On 8/16/12 9:44 AM, Paul Witty wrote: >>>>> On 15/08/12 18:57, Paul Kyzivat wrote: >>>>>> On 8/15/12 12:37 PM, Paul Witty wrote: >>>>>>> Each encoded media stream must have a distinct SSRC. If a source = is sent >>>>>>> in two separate requested captures (i.e. simulcasting of two = resolutions >>>>>>> by a transcoding middle box), then the two encodings of the same = capture >>>>>>> will have distinct SSRCs, but the SSRC of the original encoding = of the >>>>>>> source as a CSRC. >>>>>>=20 >>>>>> That seems to be in conflict with wanting to send the source SSRC = for >>>>>> switched captures. >>>>> If there is a middle box doing a transcode of a stream (for = whatever >>>>> reason, such as resolution / codec / bandwidth / packet loss >>>>> resilience), we shouldn't preserve SSRC, because the SSRC uniquely >>>>> identifies a media sender. >>>>=20 >>>> I'm no expert, but it is my impression that its permissible to have = a transcoder that preserves the SSRC. >>>>=20 >>>> Can someone who is an expert confirm or deny this? >>>=20 >>>=20 >>> You could implement the transcoder as two back-to-back RTP endpoints = and so two separate RTP sessions, where the SSRC used by the transcoder = just happens to be the same in each session. >>>=20 >>> Alternatively, you could implement the transcoder as an RFC = 3550-style translator. That could maintain the SSRC of the transcoded = stream, but would need to rewrite RTCP to match the transcoding = operation [RFC3550 section 7.2] since there would be a common RTP = session across the RTP translator. >>=20 >> Thanks Colin! >>=20 >> The latter is probably what I was thinking of. I gather this is a = fairly mainstream mechanism, rather than being something weird. >>=20 >=20 > I'm not sure mainstream is the right word; I don't believe I've ever = seen an implementation of such. It's a long-standing part of the standard, and we've seen = implementations in the past. I doubt it's a popular approach though, = since rewriting RTCP is non-trivial.=20 > A translator like this wouldn't work if a stream is being transcoded = to two simulcasted streams; as at least one of them should have a new = SSRC, which to me seems like a good reason that every transcode should = be given a new SSRC. Which makes it essentially an RTP mixer, or a back-to-back endpoint. = Both would work, of course, but are visible in the session, whereas a = pure RTP translator is not. --=20 Colin Perkins http://csperkins.org/ From pkyzivat@alum.mit.edu Mon Aug 20 12:05: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 C0DC421F86F2 for ; Mon, 20 Aug 2012 12:05:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.215 X-Spam-Level: X-Spam-Status: No, score=-2.215 tagged_above=-999 required=5 tests=[AWL=0.222, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, GB_I_INVITATION=-2, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rFJx8O78QH7w for ; Mon, 20 Aug 2012 12:05:22 -0700 (PDT) Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:24]) by ietfa.amsl.com (Postfix) with ESMTP id 42B3421F86EA for ; Mon, 20 Aug 2012 12:05:22 -0700 (PDT) Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta02.westchester.pa.mail.comcast.net with comcast id p3fp1j0061swQuc5175Qb6; Mon, 20 Aug 2012 19:05:24 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta15.westchester.pa.mail.comcast.net with comcast id p7551j00R3ZTu2S3b755zY; Mon, 20 Aug 2012 19:05:05 +0000 Message-ID: <50328A70.8020204@alum.mit.edu> Date: Mon, 20 Aug 2012 15:05:20 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: CLUE References: In-Reply-To: X-Forwarded-Message-Id: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [clue] Design Team meeting tomorrow 21-aug @ 9am CDT (GMT-5:00) 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, 20 Aug 2012 19:05:23 -0000 We are going to try to hold the design team meeting tomorrow. Mary can't make it due to a travel conflict, so I'll be chairing. But I think webex will still not work for me, so somebody else will have to grab the host role initially so that we can share. Mary is rounding up somebody to do that. There is plenty that needs to be worked on, but lets try to focus. One issue is ticket #11 (http://tools.ietf.org/wg/clue/trac/ticket/11), which has been in discussion lately. We have been having some discussion precisely on the ticket - is the extension needed? Or could the problem be solved with the static SSRC mapping. A different point came up in Vancouver (by Magnus or Colin) of whether its legal to use an RTP extension header to carry info that is essential to the functioning of clue. I'll pose four questions to discuss tomorrow about this: - can CLUE *work* without a dynamic mapping of RTP stream to capture+encoding pair? (Hence the requirement for an RTP extension.) - if so, how severe are the negative consequences of doing so? - can the capture+encoding information be conveyed with RTP in a way that is legal according to current RTP standards? - if not, how difficult and timeconsuming will it be to update those standards for what we need? If that doesn't take all the time, I'd like to discuss how to get work going on clue transport, beyond draft-wenger-clue-transport. It seems to me that we are just denying the inevitable. I'll propose a stake that I would like to drive: - the CLUE transport will be the SCTP/DTLS/UDP stack that is proposed for RTCWEB. So I'd like to hear any arguments about why we *shouldn't* drive that stake. Thanks, Paul -------- Original Message -------- Subject: Meeting invitation: CLUE Design Team Date: Mon, 13 Aug 2012 12:16:41 -0500 From: Mary Barnes To: CLUE CC: Paul Kyzivat Hi all, Below are the new Webex details for the design team meetings. I have updated the wiki as well with the info. We will shortly send the agenda for tomorrow's meeting. Mary. ---------- Forwarded message ---------- From: *Clue Working Group* > Date: Mon, Aug 13, 2012 at 12:10 PM Subject: Meeting invitation: CLUE Design Team To: mary.ietf.barnes@gmail.com Hello , Clue Working Group invites you to attend this online meeting. Topic: CLUE Design Team Date: Every Tuesday, from Tuesday, August 14, 2012 to Tuesday, March 5, 2013 Time: 9:00 am, Central Daylight Time (Chicago, GMT-05:00) Meeting Number: 642 221 028 Meeting Password: 1234 ------------------------------------------------------- To join the online meeting (Now from mobile devices!) ------------------------------------------------------- 1. Go to https://ietf.webex.com/ietf/j.php?ED=158121817&UID=1265811087&PW=NNWRkOGVjYTBh&RT=MiM3 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=158121817&UID=1265811087&PW=NNWRkOGVjYTBh&ORT=MiM3 ------------------------------------------------------- To join the audio conference only ------------------------------------------------------- Call-in toll number (US/Canada): +1-408-600-3600 Access code:642 221 028 ------------------------------------------------------- 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=158121817&UID=1265811087&ICS=MI&LD=1&RD=2&ST=1&SHA2=4FrGfPfxs/xl-6c5Pe8ihqG6MdpD-MoF6oBsrw86TDE=&RT=MiM3 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:+14086003600x642221028# 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 ron.even.tlv@gmail.com Tue Aug 21 08:17: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 6018421F84B6 for ; Tue, 21 Aug 2012 08:17:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vWi7duqPWp-8 for ; Tue, 21 Aug 2012 08:17:47 -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 9A47521F8491 for ; Tue, 21 Aug 2012 08:17:46 -0700 (PDT) Received: by weyu54 with SMTP id u54so5367218wey.31 for ; Tue, 21 Aug 2012 08:17:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:message-id:mime-version:content-type:x-mailer :thread-index:content-language; bh=pbs6yC8cayqbC9K5XjXMJRUGOvkAu3TOxj6LcW9YR0s=; b=V4Rb2mmvWRgj/L4lrU1r9bjy+BnRTiW7xeNxfUc0F3FDBio8t+fq+tErg1WFhAFobL 6EqJkCY8Tr47GaPG5Lhk5sHHlJoD2uzyQx+CtnC3Qf7KsOM73S+eizBe7pKHw8G5ipU2 pPwRyCnmuRgIXuWxjWJ1wPCJqps2pdEAlJr57ChH9zyj9M44ohzp2WhJtwbG5d2ubOdD TFqRX2C7miuzW3rhnhpU7UnVi7Gjeu2X94EAUAtzN7cmDrLFfMBVQnicvjgWtn8aD9tr NFW1xcobXQShtXFH2S+v5wUe43F+KAUjE9VhouoZpk8yP7ipnfkgz+dquDz4KdjGGVz1 3j9A== Received: by 10.180.91.228 with SMTP id ch4mr38838909wib.7.1345562265479; Tue, 21 Aug 2012 08:17:45 -0700 (PDT) Received: from RoniE ([109.64.216.128]) by mx.google.com with ESMTPS id q4sm34069932wix.9.2012.08.21.08.17.42 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 21 Aug 2012 08:17:44 -0700 (PDT) From: "Roni Even" To: Date: Tue, 21 Aug 2012 18:16:24 +0200 Message-ID: <004a01cd7fb8$51919da0$f4b4d8e0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_004B_01CD7FC9.151B5800" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac1/txUzRlUdk37wSP6k540VUMj1TQ== Content-Language: en-us Subject: [clue] the action items i took from the 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, 21 Aug 2012 15:17:48 -0000 This is a multipart message in MIME format. ------=_NextPart_000_004B_01CD7FC9.151B5800 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, This are the points I took from the meeting 1. We can use RTP header extensions but will need to update the header extension RFC about not ignoring header extensions. 2. Discussion on how to support simulcast in CLUE. Roni proposes to use the SDP support and will write a document about it 3. Is a new offer answer required for a new advertisement or configuration. Roni to address. 4. Discussion about selecting encoding for a media capture. Is the encoding only for defining physical limitation or do we use them also for selecting for example a specific encoding in a simulcast for a media capture. General question is if in a configuration you select a media capture only or also a specific type of content and how you advertise it (clarify the framework?) I hope these are what we discussed Roni ------=_NextPart_000_004B_01CD7FC9.151B5800 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

This are the = points I took from the meeting

 

1.       = We can use RTP header = extensions but will need to update the header extension RFC about not = ignoring header extensions.

2.       = Discussion on how to = support simulcast in CLUE.  Roni proposes to use the SDP support = and will write a document about it

3.       = Is a new offer answer = required for a new advertisement or configuration. Roni to = address.

4.       = Discussion about = selecting encoding for a media capture. Is the encoding only for = defining physical limitation or do we use them also for selecting for = example a specific encoding in a simulcast for a media capture. General = question is if  in a configuration you select a media capture only = or also a specific type of content and how you advertise it (clarify the = framework?)

 

I hope these are what we discussed

Roni

------=_NextPart_000_004B_01CD7FC9.151B5800-- From christer.holmberg@ericsson.com Tue Aug 21 08:32: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 ADD9821F8674 for ; Tue, 21 Aug 2012 08:32:40 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YM9RMWAR+8cN for ; Tue, 21 Aug 2012 08:32:40 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id B8A5521F84C8 for ; Tue, 21 Aug 2012 08:32:39 -0700 (PDT) X-AuditID: c1b4fb30-b7fd46d000003161-a2-5033aa162c0d Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 7B.AD.12641.61AA3305; Tue, 21 Aug 2012 17:32:38 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.99]) by esessmw0256.eemea.ericsson.se ([153.88.115.96]) with mapi; Tue, 21 Aug 2012 17:32:38 +0200 From: Christer Holmberg To: Roni Even , "clue@ietf.org" Date: Tue, 21 Aug 2012 17:31:43 +0200 Thread-Topic: [clue] the action items i took from the meeting Thread-Index: Ac1/txUzRlUdk37wSP6k540VUMj1Tf//9fkY Message-ID: <7F2072F1E0DE894DA4B517B93C6A05853409FF2EC5@ESESSCMS0356.eemea.ericsson.se> References: <004a01cd7fb8$51919da0$f4b4d8e0$@gmail.com> In-Reply-To: <004a01cd7fb8$51919da0$f4b4d8e0$@gmail.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrFLMWRmVeSWpSXmKPExsUyM+Jvra7YKuMAg30nxSz2n7rMbPG3ndmB yWPnrLvsHkuW/GQKYIrisklJzcksSy3St0vgyng05zZTwSyuivaVvewNjB0cXYwcHBICJhIb HuR2MXICmWISF+6tZ+ti5OIQEjjFKPG2+y4jhLOAUeLU22ZmkAY2AQuJ7n/aIA0iAu4STc8X soPYLAKqElPO94PZwgI2EquXPGaBqLGV6P/5jBnCNpLYtfIyG4jNKxAuMfflckYQW0jAXGJb bw8riM0JNP7HsaNg9YxAB30/tYYJxGYWEJe49WQ+E8ShAhJL9pxnhrBFJV4+/scKUS8qcad9 PSNEvZ7EjalT2CBsbYllC18zQ+wVlDg58wnLBEbRWUjGzkLSMgtJyywkLQsYWVYxCucmZuak l5vrpRZlJhcX5+fpFaduYgTGx8Etvw12MG66L3aIUZqDRUmcV091v7+QQHpiSWp2ampBalF8 UWlOavEhRiYOTqkGRh1TKett6rqzvt3IFt65+uIDISbPjypSLcGtBqLL/3sfy0ldbP3weqTJ jJD4T/GLvnYWK26e2mJSxbT9YnqY+al09c/7Tr+QcGRy0b0hfMJR/YT4+4vvuv7Yf+Ld8tFP Wn3r73sFV93WNao+uu8+yYvxs4POfp8owzOXt1mp8C4K2JWveXjLTiWW4oxEQy3mouJEAGzZ czRdAgAA Subject: Re: [clue] the action items i took from the 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, 21 Aug 2012 15:32:40 -0000 Hi, Regarding 2), note that there is a draft about simulcast and SDP: http://tools.ietf.org/id/draft-westerlund-avtcore-rtp-simulcast-01.txt Regards, Christer ________________________________ From: clue-bounces@ietf.org [clue-bounces@ietf.org] On Behalf Of Roni Even = [ron.even.tlv@gmail.com] Sent: Tuesday, August 21, 2012 7:16 PM To: clue@ietf.org Subject: [clue] the action items i took from the meeting Hi, This are the points I took from the meeting 1. We can use RTP header extensions but will need to update the heade= r extension RFC about not ignoring header extensions. 2. Discussion on how to support simulcast in CLUE. Roni proposes to = use the SDP support and will write a document about it 3. Is a new offer answer required for a new advertisement or configur= ation. Roni to address. 4. Discussion about selecting encoding for a media capture. Is the en= coding only for defining physical limitation or do we use them also for sel= ecting for example a specific encoding in a simulcast for a media capture. = General question is if in a configuration you select a media capture only = or also a specific type of content and how you advertise it (clarify the fr= amework?) I hope these are what we discussed Roni From pkyzivat@alum.mit.edu Tue Aug 21 11:12: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 0911921F8532 for ; Tue, 21 Aug 2012 11:12:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.307 X-Spam-Level: X-Spam-Status: No, score=-2.307 tagged_above=-999 required=5 tests=[AWL=0.292, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id neRrtIqEfWQB for ; Tue, 21 Aug 2012 11:12:53 -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 64BB821F8535 for ; Tue, 21 Aug 2012 11:12:51 -0700 (PDT) Received: from omta07.westchester.pa.mail.comcast.net ([76.96.62.59]) by qmta15.westchester.pa.mail.comcast.net with comcast id pPUm1j0021GhbT85FWD7LW; Tue, 21 Aug 2012 18:13:07 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta07.westchester.pa.mail.comcast.net with comcast id pWD71j00z3ZTu2S3TWD7Pe; Tue, 21 Aug 2012 18:13:08 +0000 Message-ID: <5033CFA2.50000@alum.mit.edu> Date: Tue, 21 Aug 2012 14:12:50 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: clue@ietf.org References: <004a01cd7fb8$51919da0$f4b4d8e0$@gmail.com> In-Reply-To: <004a01cd7fb8$51919da0$f4b4d8e0$@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: [clue] Notes and action items from 21-aug-2012 design team 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, 21 Aug 2012 18:12:54 -0000 Thanks Roni. I was making notes but got pulled away to something else before I could finish. So I'll add to yours. On 8/21/12 12:16 PM, Roni Even wrote: > Hi, > > This are the points I took from the meeting > > 1.We can use RTP header extensions but will need to update the header > extension RFC about not ignoring header extensions. Explanation for *why*: Jonathan spoke with Colin about it. Colin thought that such a change would not affect any existing deployments. (But note that this is all opinion. When we actually move to do this we might get surprised, so probably better to get on with it asap. And its my understanding that this is a separate issue from defining the specific new header extension we need.) > 2.Discussion on how to support simulcast in CLUE. Roni proposes to use > the SDP support and will write a document about it > > 3.Is a new offer answer required for a new advertisement or > configuration. Roni to address. An example we discussed was a session that had no presentation and wants to add one. If the presentation stream will be multiplexed on an existing media session (m-line) and will use an existing payload type for that m-line, then an O/A probably won’t be needed. If it needs to be sent using a new payload type, then a new O/A would be required before the advertisement can be sent. We didn't discuss a case where an O/A is required before sending a new configuration message - if such a case is possible. > 4.Discussion about selecting encoding for a media capture. Is the > encoding only for defining physical limitation or do we use them also > for selecting for example a specific encoding in a simulcast for a media > capture. General question is if in a configuration you select a media > capture only or also a specific type of content and how you advertise it > (clarify the framework?) My impression of the discussion of this was broader. What I understood (from the documents and the discussion today) is that the configuration selects a number of *things* (for which we currently have no name) to be received. Each of those things is a combination of one of the advertised captures and one of the advertised encodings. Its a simulcast if the same capture is selected multiple times - each in association with a different encoding. There seemed to be widespread agreement about this. ** Roni took an action item to request specific clarifications in the framework to ensure all readers get the same understanding. This then means that the RTP header extension isn't conveying a capture-id. Rather it is identifying one (or more) of these combinations of capture with encoding. If this is right, then we are lacking terminology for talking about this combination. So we need an addition to the framework to cover that too. > I hope these are what we discussed We also discussed *briefly* discussed my two questions: - can CLUE *work* without a dynamic mapping of RTP stream to capture+encoding pair? (Hence the requirement for an RTP extension.) - if so, how severe are the negative consequences of doing so? What I got from the discussion was that we probably *could*, but only by restricting the topologies we support. And that would violate our requirements. (We didn't discuss which ones. But by my reading there is one: "REQMT-13: The solution MUST support both transcoding and switching approaches to providing multipoint conferences." Thanks, Paul > Roni > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From csp@csperkins.org Tue Aug 21 13:11: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 1795721F8766 for ; Tue, 21 Aug 2012 13:11:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.549 X-Spam-Level: X-Spam-Status: No, score=-103.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DVgHPCkH2Vv2 for ; Tue, 21 Aug 2012 13:11:42 -0700 (PDT) Received: from anchor-msapost-3.mail.demon.net (anchor-msapost-3.mail.demon.net [195.173.77.166]) by ietfa.amsl.com (Postfix) with ESMTP id AE8FF21F8757 for ; Tue, 21 Aug 2012 13:11:42 -0700 (PDT) Received: from starkperkins.demon.co.uk ([80.176.158.71] helo=[192.168.0.11]) by anchor-post-3.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1T3und-0003vV-pD; Tue, 21 Aug 2012 20:11:41 +0000 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=windows-1252 From: Colin Perkins In-Reply-To: <5033CFA2.50000@alum.mit.edu> Date: Tue, 21 Aug 2012 21:11:39 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <3860D7D4-2738-4171-83FA-8CC059A6F770@csperkins.org> References: <004a01cd7fb8$51919da0$f4b4d8e0$@gmail.com> <5033CFA2.50000@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1278) Cc: clue@ietf.org Subject: Re: [clue] Notes and action items from 21-aug-2012 design team 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, 21 Aug 2012 20:11:44 -0000 On 21 Aug 2012, at 19:12, Paul Kyzivat wrote: > Thanks Roni. I was making notes but got pulled away to something else = before I could finish. So I'll add to yours. >=20 > On 8/21/12 12:16 PM, Roni Even wrote: >> Hi, >>=20 >> This are the points I took from the meeting >>=20 >> 1.We can use RTP header extensions but will need to update the header >> extension RFC about not ignoring header extensions. >=20 > Explanation for *why*: Jonathan spoke with Colin about it. Colin = thought that such a change would not affect any existing deployments. Not sure I remember a conversation like that... > (But note that this is all opinion. When we actually move to do this = we might get surprised, so probably better to get on with it asap. And = its my understanding that this is a separate issue from defining the = specific new header extension we need.) Right. RFC 5285 states that "header extensions using this specification = MUST only be used for data that can safely be ignored by the recipient = without affecting interoperability". If CLUE wants to use an RTP header = extension, it either needs to fit with those restrictions, or revise RFC = 5285 to allow whatever new uses are required. I'd expect that any update = to RFC 5285 would start by documenting the effects of relaxing the usage = restrictions, and seeing what breaks, so it can discuss the = compatibility concerns. >> 2.Discussion on how to support simulcast in CLUE. Roni proposes to = use >> the SDP support and will write a document about it >>=20 >> 3.Is a new offer answer required for a new advertisement or >> configuration. Roni to address. >=20 > An example we discussed was a session that had no presentation and = wants to add one. If the presentation stream will be multiplexed on an = existing media session (m-line) and will use an existing payload type = for that m-line, then an O/A probably won=92t be needed. If it needs to = be sent using a new payload type, then a new O/A would be required = before the advertisement can be sent. >=20 > We didn't discuss a case where an O/A is required before sending a new = configuration message - if such a case is possible. >=20 >> 4.Discussion about selecting encoding for a media capture. Is the >> encoding only for defining physical limitation or do we use them also >> for selecting for example a specific encoding in a simulcast for a = media >> capture. General question is if in a configuration you select a media >> capture only or also a specific type of content and how you advertise = it >> (clarify the framework?) >=20 > My impression of the discussion of this was broader. What I understood = (from the documents and the discussion today) is that the configuration = selects a number of *things* (for which we currently have no name) to be = received. Each of those things is a combination of one of the advertised = captures and one of the advertised encodings. Its a simulcast if the = same capture is selected multiple times - each in association with a = different encoding. There seemed to be widespread agreement about this. >=20 > ** Roni took an action item to request specific clarifications in > the framework to ensure all readers get the same understanding. >=20 > This then means that the RTP header extension isn't conveying a = capture-id. Rather it is identifying one (or more) of these combinations = of capture with encoding. >=20 > If this is right, then we are lacking terminology for talking about = this combination. So we need an addition to the framework to cover that = too. >=20 >> I hope these are what we discussed >=20 > We also discussed *briefly* discussed my two questions: >=20 > - can CLUE *work* without a dynamic mapping of RTP stream to > capture+encoding pair? (Hence the requirement for an RTP extension.) >=20 > - if so, how severe are the negative consequences of doing so? >=20 > What I got from the discussion was that we probably *could*, but only = by restricting the topologies we support. And that would violate our = requirements. (We didn't discuss which ones. But by my reading there is = one: "REQMT-13: The solution MUST support both transcoding and switching = approaches to providing multipoint conferences." >=20 > Thanks, > Paul >=20 >=20 >> Roni >>=20 >>=20 >>=20 >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >>=20 >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue --=20 Colin Perkins http://csperkins.org/ From pkyzivat@alum.mit.edu Tue Aug 21 14:03: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 5917321F853A for ; Tue, 21 Aug 2012 14:03:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.31 X-Spam-Level: X-Spam-Status: No, score=-2.31 tagged_above=-999 required=5 tests=[AWL=0.289, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hhN-EcS9vKwH for ; Tue, 21 Aug 2012 14:03:39 -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 A7C7F21F84F5 for ; Tue, 21 Aug 2012 14:03:38 -0700 (PDT) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta13.westchester.pa.mail.comcast.net with comcast id pStT1j0041c6gX85DZ3hi3; Tue, 21 Aug 2012 21:03:41 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta23.westchester.pa.mail.comcast.net with comcast id pZ3J1j00H3ZTu2S3jZ3JLh; Tue, 21 Aug 2012 21:03:18 +0000 Message-ID: <5033F7A5.3090703@alum.mit.edu> Date: Tue, 21 Aug 2012 17:03:33 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Colin Perkins References: <004a01cd7fb8$51919da0$f4b4d8e0$@gmail.com> <5033CFA2.50000@alum.mit.edu> <3860D7D4-2738-4171-83FA-8CC059A6F770@csperkins.org> In-Reply-To: <3860D7D4-2738-4171-83FA-8CC059A6F770@csperkins.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: clue@ietf.org Subject: Re: [clue] Notes and action items from 21-aug-2012 design team 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, 21 Aug 2012 21:03:40 -0000 On 8/21/12 4:11 PM, Colin Perkins wrote: > On 21 Aug 2012, at 19:12, Paul Kyzivat wrote: >> Thanks Roni. I was making notes but got pulled away to something else before I could finish. So I'll add to yours. >> >> On 8/21/12 12:16 PM, Roni Even wrote: >>> Hi, >>> >>> This are the points I took from the meeting >>> >>> 1.We can use RTP header extensions but will need to update the header >>> extension RFC about not ignoring header extensions. >> >> Explanation for *why*: Jonathan spoke with Colin about it. Colin thought that such a change would not affect any existing deployments. > > Not sure I remember a conversation like that... That's the trouble with heresay - especially if I might have noted it down wrong. >> (But note that this is all opinion. When we actually move to do this we might get surprised, so probably better to get on with it asap. And its my understanding that this is a separate issue from defining the specific new header extension we need.) > > Right. RFC 5285 states that "header extensions using this specification MUST only be used for data that can safely be ignored by the recipient without affecting interoperability". If CLUE wants to use an RTP header extension, it either needs to fit with those restrictions, or revise RFC 5285 to allow whatever new uses are required. I'd expect that any update to RFC 5285 would start by documenting the effects of relaxing the usage restrictions, and seeing what breaks, so it can discuss the compatibility concerns. I know you can accurately predict the future, but what do you think the chances are of getting something like that approved, and how long it might take? (And feel free to factor in whether you would be supporting or opposing it.) Thanks, Paul From ron.even.tlv@gmail.com Tue Aug 21 14:15: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 2980021F8593 for ; Tue, 21 Aug 2012 14:15:10 -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.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pk-RIMDli7iU for ; Tue, 21 Aug 2012 14:15:09 -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 358BD21F858A for ; Tue, 21 Aug 2012 14:15:09 -0700 (PDT) Received: by wicr5 with SMTP id r5so4084983wic.13 for ; Tue, 21 Aug 2012 14:15:08 -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=5aI+tlfCgZUUK8BJ037YyEAZcQdNK1K5QH5Yv+qNc/A=; b=SSR6ehmocOYP1V9Nlx0b0UMxLCxeJR5dCRP2cLGPlmkvFbZIN+ySY2fwqmtX2xf+Xd 96xseiBhCkA7BZ7wea46OOw/6T5j++Gxh6TC2GU9/opedDBCBTqKHOEMCv81OHr0q+Pu 4lNW2bbDZQOVpU7e3xmW7uDWTLF1+77DFx0QafnG7SJ0Uc5DsYWx4uONgAxqX4o8z9r3 4h76buhPxgCgO6lWmrq3XkDN+/G2IBIzuMkwYdhheq5vLeM2nrjDwd7mXwaCBPtFKoY1 nDgHCa7PtjPIi1Pim6Tc6C6q3AHdgIjp+K1CZG0G/f9LXZwarv4gRU/5Od96REaG4Bcy v9+g== Received: by 10.180.78.99 with SMTP id a3mr39389072wix.15.1345583708170; Tue, 21 Aug 2012 14:15:08 -0700 (PDT) Received: from RoniE ([109.64.216.128]) by mx.google.com with ESMTPS id dc3sm35595991wib.7.2012.08.21.14.15.05 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 21 Aug 2012 14:15:07 -0700 (PDT) From: "Roni Even" To: "'Paul Kyzivat'" , References: <004a01cd7fb8$51919da0$f4b4d8e0$@gmail.com> <5033CFA2.50000@alum.mit.edu> In-Reply-To: <5033CFA2.50000@alum.mit.edu> Date: Wed, 22 Aug 2012 00:13:48 +0200 Message-ID: <006901cd7fea$3e8b8c20$bba2a460$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIm8qRg8ZZqP+83BAq7zn6qL3zShgJIWkJ2lp+rWnA= Content-Language: en-us Subject: Re: [clue] Notes and action items from 21-aug-2012 design team 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, 21 Aug 2012 21:15:10 -0000 Hi Paul, In number 4 this is not my action item. The current framework does not mention this usage for encoding groups and Paul Wity should point where it does. I still think that we amp a capture ID. There may be more than one SSRC mapped to the same capture id I was making a general comment on the readability of the encoding group support in the framework Roni -----Original Message----- From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: 21 August, 2012 8:13 PM To: clue@ietf.org Subject: [clue] Notes and action items from 21-aug-2012 design team meeting Thanks Roni. I was making notes but got pulled away to something else before I could finish. So I'll add to yours. > 4.Discussion about selecting encoding for a media capture. Is the > encoding only for defining physical limitation or do we use them also > for selecting for example a specific encoding in a simulcast for a > media capture. General question is if in a configuration you select a > media capture only or also a specific type of content and how you > advertise it (clarify the framework?) My impression of the discussion of this was broader. What I understood (from the documents and the discussion today) is that the configuration selects a number of *things* (for which we currently have no name) to be received. Each of those things is a combination of one of the advertised captures and one of the advertised encodings. Its a simulcast if the same capture is selected multiple times - each in association with a different encoding. There seemed to be widespread agreement about this. ** Roni took an action item to request specific clarifications in the framework to ensure all readers get the same understanding. This then means that the RTP header extension isn't conveying a capture-id. Rather it is identifying one (or more) of these combinations of capture with encoding. If this is right, then we are lacking terminology for talking about this combination. So we need an addition to the framework to cover that too. > I hope these are what we discussed We also discussed *briefly* discussed my two questions: - can CLUE *work* without a dynamic mapping of RTP stream to capture+encoding pair? (Hence the requirement for an RTP extension.) - if so, how severe are the negative consequences of doing so? What I got from the discussion was that we probably *could*, but only by restricting the topologies we support. And that would violate our requirements. (We didn't discuss which ones. But by my reading there is one: "REQMT-13: The solution MUST support both transcoding and switching approaches to providing multipoint conferences." Thanks, Paul > 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 csp@csperkins.org Tue Aug 21 14:20: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 413F321F85C7 for ; Tue, 21 Aug 2012 14:20:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.552 X-Spam-Level: X-Spam-Status: No, score=-103.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T3C+al5Z9ogz for ; Tue, 21 Aug 2012 14:20:09 -0700 (PDT) Received: from lon1-msapost-2.mail.demon.net (lon1-msapost-2.mail.demon.net [195.173.77.181]) by ietfa.amsl.com (Postfix) with ESMTP id 479DB21F85D5 for ; Tue, 21 Aug 2012 14:20:09 -0700 (PDT) Received: from starkperkins.demon.co.uk ([80.176.158.71] helo=[192.168.0.11]) by lon1-post-2.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1T3vrs-00040Q-ao; Tue, 21 Aug 2012 21:20:08 +0000 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=windows-1252 From: Colin Perkins In-Reply-To: <5033F7A5.3090703@alum.mit.edu> Date: Tue, 21 Aug 2012 22:20:04 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <004a01cd7fb8$51919da0$f4b4d8e0$@gmail.com> <5033CFA2.50000@alum.mit.edu> <3860D7D4-2738-4171-83FA-8CC059A6F770@csperkins.org> <5033F7A5.3090703@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1278) Cc: clue@ietf.org Subject: Re: [clue] Notes and action items from 21-aug-2012 design team 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, 21 Aug 2012 21:20:10 -0000 On 21 Aug 2012, at 22:03, Paul Kyzivat wrote: > On 8/21/12 4:11 PM, Colin Perkins wrote: >> On 21 Aug 2012, at 19:12, Paul Kyzivat wrote: ... >>> (But note that this is all opinion. When we actually move to do this = we might get surprised, so probably better to get on with it asap. And = its my understanding that this is a separate issue from defining the = specific new header extension we need.) >>=20 >> Right. RFC 5285 states that "header extensions using this = specification MUST only be used for data that can safely be ignored by = the recipient without affecting interoperability". If CLUE wants to use = an RTP header extension, it either needs to fit with those restrictions, = or revise RFC 5285 to allow whatever new uses are required. I'd expect = that any update to RFC 5285 would start by documenting the effects of = relaxing the usage restrictions, and seeing what breaks, so it can = discuss the compatibility concerns. >=20 > I know you can accurately predict the future, but what do you think = the chances are of getting something like that approved, and how long it = might take? (And feel free to factor in whether you would be supporting = or opposing it.) The text about this in RFCs 3550 and 5285 is there for a reason. If you = can explain why that reason is no longer a concern, and show that there = are no significant backwards compatibility issues, then I'd expect this = could move fairly quickly. If there's no convincing reason why this is = acceptable now but wasn't when the standards were written, then it may = take longer. It's difficult to be more precise without having seen a = draft... --=20 Colin Perkins http://csperkins.org/ From pkyzivat@alum.mit.edu Tue Aug 21 15:03: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 A890E21F8613 for ; Tue, 21 Aug 2012 15:03:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.313 X-Spam-Level: X-Spam-Status: No, score=-2.313 tagged_above=-999 required=5 tests=[AWL=0.286, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ZsDBGBv9jUC for ; Tue, 21 Aug 2012 15:03:07 -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 804DE21F85A8 for ; Tue, 21 Aug 2012 15:03:06 -0700 (PDT) Received: from omta03.westchester.pa.mail.comcast.net ([76.96.62.27]) by qmta08.westchester.pa.mail.comcast.net with comcast id pYE51j0090bG4ec58a39m1; Tue, 21 Aug 2012 22:03:09 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta03.westchester.pa.mail.comcast.net with comcast id pa321j00J3ZTu2S3Pa32Uz; Tue, 21 Aug 2012 22:03:02 +0000 Message-ID: <50340599.6000905@alum.mit.edu> Date: Tue, 21 Aug 2012 18:03:05 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Roni Even References: <004a01cd7fb8$51919da0$f4b4d8e0$@gmail.com> <5033CFA2.50000@alum.mit.edu> <006901cd7fea$3e8b8c20$bba2a460$@gmail.com> In-Reply-To: <006901cd7fea$3e8b8c20$bba2a460$@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: clue@ietf.org Subject: Re: [clue] Notes and action items from 21-aug-2012 design team 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, 21 Aug 2012 22:03:07 -0000 On 8/21/12 6:13 PM, Roni Even wrote: > Hi Paul, > In number 4 this is not my action item. Well, I *tried* to give it to you. :-) > The current framework does not mention this usage for encoding groups and > Paul Wity should point where it does. I'm not sure, but I *think* you are alone in not getting this understanding. Maybe its implicit rather than explicit. But I was thinking if you are the one who didn't get it you would best be able to say why. But maybe not. If its implicit then maybe someone who does infer it needs to spell out what led to that inference. > I still think that we amp a capture ID. There may be more than one SSRC > mapped to the same capture id If the configure message simply specified which captures it wanted, without saying which encoding to use, then how is the decision about encoding made? Does the sender choose? If the sender chooses, then what is the point of putting encodings into the advertisement? And, if the recipient wants multiple encodings of the same capture, how would it request that? Thanks, Paul > I was making a general comment on the readability of the encoding group > support in the framework > > > > Roni > > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Paul > Kyzivat > Sent: 21 August, 2012 8:13 PM > To: clue@ietf.org > Subject: [clue] Notes and action items from 21-aug-2012 design team meeting > > Thanks Roni. I was making notes but got pulled away to something else before > I could finish. So I'll add to yours. > > >> 4.Discussion about selecting encoding for a media capture. Is the >> encoding only for defining physical limitation or do we use them also >> for selecting for example a specific encoding in a simulcast for a >> media capture. General question is if in a configuration you select a >> media capture only or also a specific type of content and how you >> advertise it (clarify the framework?) > > My impression of the discussion of this was broader. What I understood (from > the documents and the discussion today) is that the configuration selects a > number of *things* (for which we currently have no name) to be received. > Each of those things is a combination of one of the advertised captures and > one of the advertised encodings. Its a simulcast if the same capture is > selected multiple times - each in association with a different encoding. > There seemed to be widespread agreement about this. > > ** Roni took an action item to request specific clarifications in > the framework to ensure all readers get the same understanding. > > > > This then means that the RTP header extension isn't conveying a capture-id. > Rather it is identifying one (or more) of these combinations of capture with > encoding. > > If this is right, then we are lacking terminology for talking about this > combination. So we need an addition to the framework to cover that too. > >> I hope these are what we discussed > > We also discussed *briefly* discussed my two questions: > > - can CLUE *work* without a dynamic mapping of RTP stream to > capture+encoding pair? (Hence the requirement for an RTP extension.) > > - if so, how severe are the negative consequences of doing so? > > What I got from the discussion was that we probably *could*, but only by > restricting the topologies we support. And that would violate our > requirements. (We didn't discuss which ones. But by my reading there is > one: "REQMT-13: The solution MUST support both transcoding and switching > approaches to providing multipoint conferences." > > Thanks, > Paul > > >> 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 john@jlc.net Tue Aug 21 15: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 78CC421F867A for ; Tue, 21 Aug 2012 15:06:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.756 X-Spam-Level: X-Spam-Status: No, score=-105.756 tagged_above=-999 required=5 tests=[AWL=0.843, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2mLSVjfuwSnW for ; Tue, 21 Aug 2012 15:06:59 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id EC4EF21F8608 for ; Tue, 21 Aug 2012 15:06:58 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id BF1BC33C26; Tue, 21 Aug 2012 18:06:58 -0400 (EDT) Date: Tue, 21 Aug 2012 18:06:58 -0400 From: John Leslie To: Paul Kyzivat Message-ID: <20120821220658.GL85937@verdi> References: <004a01cd7fb8$51919da0$f4b4d8e0$@gmail.com> <5033CFA2.50000@alum.mit.edu> <3860D7D4-2738-4171-83FA-8CC059A6F770@csperkins.org> <5033F7A5.3090703@alum.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5033F7A5.3090703@alum.mit.edu> User-Agent: Mutt/1.4.1i Cc: clue@ietf.org Subject: Re: [clue] Notes and action items from 21-aug-2012 design team 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, 21 Aug 2012 22:06:59 -0000 Paul Kyzivat wrote: > On 8/21/12 4:11 PM, Colin Perkins wrote: >> >> Right. RFC 5285 states that "header extensions using this specification >> MUST only be used for data that can safely be ignored by the recipient >> without affecting interoperability". If CLUE wants to use an RTP header >> extension, it either needs to fit with those restrictions, or revise RFC >> 5285 to allow whatever new uses are required. I'd expect that any update >> to RFC 5285 would start by documenting the effects of relaxing the usage >> restrictions, and seeing what breaks, so it can discuss the compatibility >> concerns. > > ... what do you think the chances are of getting something like that > approved, and how long it might take? There are _so_ many things I don't understand here that a wiser man would certainly keep quiet... Nonetheless, this piece of 5285 strikes me as awfully fundamental to it: 5285 does _not_ "update" 3550: thus usage of it must not invalidate other possible interpretations of 3550. We have no basis for expecting receivers of RTP packets to pay any attention to 5285: thus IMHO it MUST be valid for them to ignore 5285 header extensions. I'd like somebody to explain why we want anything to do with 5285. It would seem to make more sense for us to define a different interpretation of a 3550 header extension. But I don't even understand why we want to use an RTP header "extension" at all. :^( (It _might_ turn out that I'm not the only confused WG participant.) -- John Leslie From ron.even.tlv@gmail.com Tue Aug 21 22:14: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 4069F21F84CE for ; Tue, 21 Aug 2012 22:14:38 -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.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kbmb-SOlfgEB for ; Tue, 21 Aug 2012 22:14:34 -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 939D121F8493 for ; Tue, 21 Aug 2012 22:14:33 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so310989wgb.13 for ; Tue, 21 Aug 2012 22:14:32 -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=75L0Do5v1KLcjvxvtvyhtRT+/H4JEHPyGpjyfzLJ/G8=; b=n+U3M6t/TdNyJ2XIPao3KrVxS7hkq4ldy11ZtgFwAvjoXLG9fBXxMlTOSnVAxfL4ox TIYKBo1lDdZla/rbste/9OJxOK8xogDPD29iYyVvsqrOOItL+Aw70waWGq4pmMVXDr3E jU+h985b49WjEASvZmmfniQ1FxkpvfwL6oGBwxmyYMcASTZ0x2fQquzXYARhCLqOHSVK 7P8hsMM24gGZs26pjr6d7CQTpV9O5Pe9uroRCp81byOclWQPOpAOxA8frnEgSqzHC2No H03cwLG4gF+qSYLt9ZDJq3k3LjwC92UmP7tTgTkgBliSIyBYtEzYy3YmbdCLr4LkplJI Xzvg== Received: by 10.216.59.7 with SMTP id r7mr11047488wec.19.1345612472484; Tue, 21 Aug 2012 22:14:32 -0700 (PDT) Received: from RoniE ([109.64.216.128]) by mx.google.com with ESMTPS id fb20sm9786388wid.1.2012.08.21.22.14.29 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 21 Aug 2012 22:14:31 -0700 (PDT) From: "Roni Even" To: "'Paul Kyzivat'" References: <004a01cd7fb8$51919da0$f4b4d8e0$@gmail.com> <5033CFA2.50000@alum.mit.edu> <006901cd7fea$3e8b8c20$bba2a460$@gmail.com> <50340599.6000905@alum.mit.edu> In-Reply-To: <50340599.6000905@alum.mit.edu> Date: Wed, 22 Aug 2012 08:13:11 +0200 Message-ID: <001f01cd802d$3748bd50$a5da37f0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIm8qRg8ZZqP+83BAq7zn6qL3zShgJIWkJ2AZIxFQ8CrWcfu5Z+M7IA Content-Language: en-us Cc: clue@ietf.org Subject: Re: [clue] Notes and action items from 21-aug-2012 design team 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, 22 Aug 2012 05:14:38 -0000 Paul, I can see that it is feasible to define individual encodes this way. The issue is that the use case for the encodes as stated in the framework is to address physical constrains, when supporting multiple simultaneous streams. If the idea was to use it for simulcast, it should state it. It was never mentioned that the purpose is to support simulcast or any image control functionality. If you want to use it to specify the image size by the consumer it misses parameters currently available in the SDP image attribute Roni -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] Sent: 22 August, 2012 12:03 AM To: Roni Even Cc: clue@ietf.org Subject: Re: [clue] Notes and action items from 21-aug-2012 design team meeting On 8/21/12 6:13 PM, Roni Even wrote: > Hi Paul, > In number 4 this is not my action item. Well, I *tried* to give it to you. :-) > The current framework does not mention this usage for encoding groups > and Paul Wity should point where it does. I'm not sure, but I *think* you are alone in not getting this understanding. Maybe its implicit rather than explicit. But I was thinking if you are the one who didn't get it you would best be able to say why. But maybe not. If its implicit then maybe someone who does infer it needs to spell out what led to that inference. > I still think that we amp a capture ID. There may be more than one > SSRC mapped to the same capture id If the configure message simply specified which captures it wanted, without saying which encoding to use, then how is the decision about encoding made? Does the sender choose? If the sender chooses, then what is the point of putting encodings into the advertisement? And, if the recipient wants multiple encodings of the same capture, how would it request that? Thanks, Paul > I was making a general comment on the readability of the encoding > group support in the framework > > > > Roni > > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf > Of Paul Kyzivat > Sent: 21 August, 2012 8:13 PM > To: clue@ietf.org > Subject: [clue] Notes and action items from 21-aug-2012 design team > meeting > > Thanks Roni. I was making notes but got pulled away to something else > before I could finish. So I'll add to yours. > > >> 4.Discussion about selecting encoding for a media capture. Is the >> encoding only for defining physical limitation or do we use them also >> for selecting for example a specific encoding in a simulcast for a >> media capture. General question is if in a configuration you select a >> media capture only or also a specific type of content and how you >> advertise it (clarify the framework?) > > My impression of the discussion of this was broader. What I understood > (from the documents and the discussion today) is that the > configuration selects a number of *things* (for which we currently have no name) to be received. > Each of those things is a combination of one of the advertised > captures and one of the advertised encodings. Its a simulcast if the > same capture is selected multiple times - each in association with a different encoding. > There seemed to be widespread agreement about this. > > ** Roni took an action item to request specific clarifications in > the framework to ensure all readers get the same understanding. > > > > This then means that the RTP header extension isn't conveying a capture-id. > Rather it is identifying one (or more) of these combinations of > capture with encoding. > > If this is right, then we are lacking terminology for talking about > this combination. So we need an addition to the framework to cover that too. > >> I hope these are what we discussed > > We also discussed *briefly* discussed my two questions: > > - can CLUE *work* without a dynamic mapping of RTP stream to > capture+encoding pair? (Hence the requirement for an RTP > extension.) > > - if so, how severe are the negative consequences of doing so? > > What I got from the discussion was that we probably *could*, but only > by restricting the topologies we support. And that would violate our > requirements. (We didn't discuss which ones. But by my reading there > is > one: "REQMT-13: The solution MUST support both transcoding and > switching approaches to providing multipoint conferences." > > Thanks, > Paul > > >> 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 apeppere@gmail.com Wed Aug 22 00:25: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 4427F21F8494 for ; Wed, 22 Aug 2012 00:25:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.361 X-Spam-Level: X-Spam-Status: No, score=-3.361 tagged_above=-999 required=5 tests=[AWL=0.237, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1WJAFPOsnhhF for ; Wed, 22 Aug 2012 00:25:56 -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 3324921F8475 for ; Wed, 22 Aug 2012 00:25:56 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so766426vcb.31 for ; Wed, 22 Aug 2012 00:25: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=f54tTVDTYrSR7ogbnnfsf4sYqXtbLhDqyhjYakEBOaw=; b=LTT1n5RCLZlx5bao0Fg87zCDYNtrp+VE9pGWvqWccuFKImfFcedPq0sesyESpt38qM f++cDHxmf+eadJaClv+bBzc82E1V96vAAZ8AjS4nEMaaWCyO2qrGncbOaelamR3USm6L I4qkP80+tfe2BmfbouYeaI28kziE5XLZkA3tgJWbBFhNfrm7ArYJa7OAfgYerX/YuA0i pFkNVJ6qFISS/yrNjFXA0vdJaOHnaQx7JiOj/9MNrHL/b0PcdnGNd5al23w8IF+LFua4 5o7cxllgjjJNC87AFi1utEoExTswgpJgHmxR6mtR1XW6lzOIgQ1loquEr2Hayyu3nQpQ HQDA== MIME-Version: 1.0 Received: by 10.220.153.7 with SMTP id i7mr15718101vcw.34.1345620355633; Wed, 22 Aug 2012 00:25:55 -0700 (PDT) Received: by 10.220.44.132 with HTTP; Wed, 22 Aug 2012 00:25:55 -0700 (PDT) In-Reply-To: <006901cd7fea$3e8b8c20$bba2a460$@gmail.com> References: <004a01cd7fb8$51919da0$f4b4d8e0$@gmail.com> <5033CFA2.50000@alum.mit.edu> <006901cd7fea$3e8b8c20$bba2a460$@gmail.com> Date: Wed, 22 Aug 2012 08:25:55 +0100 Message-ID: From: Andy Pepperell To: Roni Even Content-Type: multipart/alternative; boundary=f46d043c7c7c4cd02f04c7d5a7a7 Cc: clue@ietf.org Subject: Re: [clue] Notes and action items from 21-aug-2012 design team 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, 22 Aug 2012 07:25:57 -0000 --f46d043c7c7c4cd02f04c7d5a7a7 Content-Type: text/plain; charset=ISO-8859-1 Hi Roni On Tue, Aug 21, 2012 at 11:13 PM, Roni Even wrote: > Hi Paul, > The current framework does not mention this usage for encoding groups and > > I was making a general comment on the readability of the encoding group > support in the framework > > I think it was me that made the rash promise to ensure that the framework was clear on this point :) >From what I remember in the meeting what we said needing clarification was being able to instantiate a single capture into multiple encodings - to address this first, the framework talks about this in section 8, for instance: *Every media capture is associated with an encoding group, which is used to instantiate that media capture into one or more encoded streams.* and: *If there are multiple individual encodings in the group, then a single media capture can be encoded into multiple different streams at the same time...* and from section 9: *For each media capture the consumer wants to receive, it configures one or more of the encodings in that capture's encoding group* >[Roni] >I was making a general comment on the readability of the encoding group support in the framework I'm not sure how to answer this one, except perhaps asking you to make a more specific comment on the readability of the encoding group support in the framework... :) >Is the encoding only for defining physical limitation or do we use them also for selecting for example a specific encoding in a simulcast for a media capture. To attempt an answer on this one, yes, it's true that one usage of the encoding group system was to ensure that today's Telepresence endpoint devices which are typically formed of 2, 3, or 4 distinct regular endpoints with some additional control logic were well represented - specifically the likely constraint that only, say, the DSP resource on the device connected to the leftmost camera would be able to produce encodings of that camera's media capture. However, it would be wrong to say that the encoding group system is "only for defining physical limitation" as that's only one use, and we didn't want to be too prescriptive - a single-box software MCU might sensibly separate out its main and presentation encodings with separate encoding groups, or use this scheme to capture nuances of switched vs transcoded. >General question is if in a configuration you select a media capture only or also a specific type of content and how you advertise it (clarify the framework?) The configuration (consumer stream choice) mechanism is intended to allow the consumer to select both the set of capture encodings it wishes the provider to send to it, plus characteristics of those encodings such as maximum bandwidth / resolution etc. (all of which would be subject to SIP call level overall restrictions as conveyed by SDP, which would also define payload types etc. as now). > (clarify the framework?) I think it's a fair comment on the framework that, as compared to the level of detail and number of example cases relating to provider advertisements and encoding groups then the configuration / consumer stream choice side of things is perhaps under-represented in the document. This may be something worth addressing - additionally, the messaging / data model document will by necessity contain full details of all of these aspects. Regards, Andy --f46d043c7c7c4cd02f04c7d5a7a7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Roni

On Tue, Aug 21, 2012 at 11:13 PM,= Roni Even <ron.even.tlv@gmail.com> wrote:
Hi Paul,
The current framework does not mention this usage for encoding = groups and
=A0
I was making a general comment on the readability of the encoding group
support in the framework

=A0
I think it = was me that made the rash promise to ensure that the framework was clear on= this point :)

From what I remember in the meeting= what we said needing clarification was being able to instantiate a single = capture into multiple encodings - to address this first, the framework talk= s about this in section 8, for instance:
Every media capture is associated with an encoding group, which is= =A0used to instantiate that media capture into one or more encoded=A0stream= s.
and:
If there are multiple=A0individual = encodings in the group, then a single media capture can be=A0encoded into m= ultiple different streams at the same time...
and from section 9:
For each media capture the= consumer wants to receive, it configures=A0one or more of the encodings in= that capture's encoding group

>[= Roni]
>I was making a general comment on the readability of the enco= ding group=A0support in the framework

I'= m not sure how to answer this one, except perhaps asking you to make a more= specific comment on the readability of the encoding group support in the f= ramework... :)

>Is the=A0encoding only for defining physical limita= tion or do we use them also=A0for selecting for example a specific encoding= in a simulcast for a media
capture.=A0

=
To attempt an answer on this one, yes, it's true that one usage of= the encoding group system was to ensure that today's Telepresence endp= oint devices which are typically formed of 2, 3, or 4 distinct regular endp= oints with some additional control logic were well represented - specifical= ly the likely constraint that only, say, the DSP resource on the device con= nected to the leftmost camera would be able to produce encodings of that ca= mera's media capture. However, it would be wrong to say that the encodi= ng group system is "only for defining physical limitation" as tha= t's only one use, and we didn't want to be too prescriptive - a sin= gle-box software MCU might sensibly separate out its main and presentation = encodings with separate encoding groups, or use this scheme to capture nuan= ces of switched vs transcoded.

>General question is if in a configuration you selec= t a media capture only or also a specific type of content and how you adver= tise it (clarify the framework?)

The configuration= (consumer stream choice) mechanism is intended to allow the consumer to se= lect both the set of capture encodings it wishes the provider to send to it= , plus characteristics of those encodings such as maximum bandwidth / resol= ution etc. (all of which would be subject to SIP call level overall restric= tions as conveyed by SDP, which would also define payload types etc. as now= ).

>=A0=A0(clarify the framework?)
I think it= 's a fair comment on the framework that, as compared to the level of de= tail and number of example cases relating to provider advertisements and en= coding groups then the configuration / consumer stream choice side of thing= s is perhaps under-represented in the document. This may be something worth= addressing - additionally, the messaging / data model document will by nec= essity contain full details of all of these aspects.

Regards,

Andy

--f46d043c7c7c4cd02f04c7d5a7a7-- From apeppere@gmail.com Wed Aug 22 00:48: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 9399121F85D5 for ; Wed, 22 Aug 2012 00:48:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.381 X-Spam-Level: X-Spam-Status: No, score=-3.381 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZmpOtnqdfJKQ for ; Wed, 22 Aug 2012 00:48:08 -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 A5B5921F85C4 for ; Wed, 22 Aug 2012 00:48:08 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so786156vcb.31 for ; Wed, 22 Aug 2012 00:48: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=NAVUtoVyOvCS2GcjQkvevquwRS891s8aCEJNqvASAeI=; b=fhMOy1Aqn63R1QQSVhcgVhj4UWYTB3IOJsvlPmQZ69HiYJw+OzYSk4Qq39dL81Sk4x Bhx1kSmxtqRqYcCNv5+k+u/4FA8bqHpm76ctaqZ4hB3X1ooEfADJqhjetEndCC9fMnRd Y79cj1IbJpoTE1CYyPz8ePkQe2587mb3g+eu9ERpx6MdW0izmRIV1lhk5yU6ZxQDwEgJ X3OIHpxjAVuH2go92R/r6cYlhwmfD1cO64h8QzfdfPa/i+zS2+FUgPw1fwk4P5+igZvl O38DKh+A+nwCc3hBtoyd3I5bdFWprMXIfOVp84tzYz6/LXonks7iY2N+tkSUAbp8gEgk dhnQ== MIME-Version: 1.0 Received: by 10.59.1.162 with SMTP id bh2mr9599136ved.13.1345621688026; Wed, 22 Aug 2012 00:48:08 -0700 (PDT) Received: by 10.220.44.132 with HTTP; Wed, 22 Aug 2012 00:48:07 -0700 (PDT) In-Reply-To: <001f01cd802d$3748bd50$a5da37f0$@gmail.com> References: <004a01cd7fb8$51919da0$f4b4d8e0$@gmail.com> <5033CFA2.50000@alum.mit.edu> <006901cd7fea$3e8b8c20$bba2a460$@gmail.com> <50340599.6000905@alum.mit.edu> <001f01cd802d$3748bd50$a5da37f0$@gmail.com> Date: Wed, 22 Aug 2012 08:48:07 +0100 Message-ID: From: Andy Pepperell To: Roni Even Content-Type: multipart/alternative; boundary=047d7bdc808eb7867204c7d5f6bf Cc: clue@ietf.org Subject: Re: [clue] Notes and action items from 21-aug-2012 design team 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, 22 Aug 2012 07:48:09 -0000 --047d7bdc808eb7867204c7d5f6bf Content-Type: text/plain; charset=ISO-8859-1 On Wed, Aug 22, 2012 at 7:13 AM, Roni Even wrote: > Paul, > I can see that it is feasible to define individual encodes this way. The > issue is that the use case for the encodes as stated in the framework is to > address physical constrains, when supporting multiple simultaneous streams. > If the idea was to use it for simulcast, it should state it. In a sense the framework was written to explain the general-purpose mechanisms available without being too prescriptive about their uses - the idea of the abstract media captures, provider advertisement and the ways in which a consumer could use this information does talk in more than one place about instantiating multiple encodings of the same media capture - our view (which could obviously be revised based on feedback!) was that this was sufficient and didn't need labelling as "simulcast", which might mean different things to different people... Your comment seems to be tying together encoding groups (one use of which is to express physical constraints) and simulcast, whereas in fact these are in a sense orthogonal aspects of the framework - specifically, a system with no constraints requiring it to express its encoding capabilities in more than one encoding group might still be perfectly happy to provide multiple versions of all of its media captures. A system capable of producing only one encoding of a media capture would need to ensure that capture was associated with an encoding group comprising just one potential encoding - it would depend on the nature of the provider-side equipment whether a "physical" or other type of constraint was imposing that restriction, so we didn't feel it useful to dictate that in the framework document. > It was never > mentioned that the purpose is to support simulcast or any image control > functionality. If you want to use it to specify the image size by the > consumer it misses parameters currently available in the SDP image > attribute > I think we've already had a long thread on the topic of whether such parameters transported via SDP works well within CLUE... I don't think it does - e.g. considering the case where a consumer is receiving multiple active speakers and composing them itself into a layout then it needs to tell the provider the display size characteristics of those speakers' streams, and, moreover, tell the provider new values when it decides to use a different layout (at which point it would seem wrong to force a new Offer/Answer). Similarly, a provider might want to tell its associated CLUE consumer(s) about a 4:3 / 16:9 aspect ratio change in a presentation video channel without a new Offer/Answer. Regards, Andy --047d7bdc808eb7867204c7d5f6bf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Aug 22, 2012 at 7:13 AM, Roni Even <ron.even.tlv@gmail.com> wrote:
Paul,
I can see that it is feasible to define individual encodes this way. The issue is that the use case for the encodes as stated in the framework is to=
address physical constrains, when supporting multiple simultaneous streams.=
If the idea was to use it for simulcast, it should state it.

In a sense the framework was written to explain the gener= al-purpose mechanisms available without being too prescriptive about their = uses - the idea of the abstract media captures, provider advertisement and = the ways in which a consumer could use this information does talk in more t= han one place about instantiating multiple encodings of the same media capt= ure - our view (which could obviously be revised based on feedback!) was th= at this was sufficient and didn't need labelling as "simulcast&quo= t;, which might mean different things to different people...

Your comment seems to be tying together encoding groups= (one use of which is to express physical constraints) and simulcast, where= as in fact these are in a sense orthogonal aspects of the framework - speci= fically, a system with no constraints requiring it to express its encoding = capabilities in more than one encoding group might still be perfectly happy= to provide multiple versions of all of its media captures. A system capabl= e of producing only one encoding of a media capture would need to ensure th= at capture was associated with an encoding group comprising just one potent= ial encoding - it would depend on the nature of the provider-side equipment= whether a "physical" or other type of constraint was imposing th= at restriction, so we didn't feel it useful to dictate that in the fram= ework document.

=A0
=A0It was neve= r
mentioned that the purpose is to support simulcast or any image control
functionality. If you want to use it to specify the image size by the
consumer it misses parameters currently available in the SDP image attribut= e

I think we've already had a long = thread on the topic of whether such parameters transported via SDP works we= ll within CLUE... I don't think it does - e.g. considering the case whe= re a consumer is receiving multiple active speakers and composing them itse= lf into a layout then it needs to tell the provider the display size charac= teristics of those speakers' streams, and, moreover, tell the provider = new values when it decides to use a different layout (at which point it wou= ld seem wrong to force a new Offer/Answer). Similarly, a provider might wan= t to tell its associated CLUE consumer(s) about a 4:3 / 16:9 aspect ratio c= hange in a presentation video channel without a new Offer/Answer.

Regards,

Andy

--047d7bdc808eb7867204c7d5f6bf-- From pkyzivat@alum.mit.edu Wed Aug 22 07:54: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 C89B421F8598 for ; Wed, 22 Aug 2012 07:54:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.227 X-Spam-Level: X-Spam-Status: No, score=-1.227 tagged_above=-999 required=5 tests=[AWL=-0.790, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C6e5pa8dZ-Ty for ; Wed, 22 Aug 2012 07:54:49 -0700 (PDT) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:16]) by ietfa.amsl.com (Postfix) with ESMTP id AA11821F84F5 for ; Wed, 22 Aug 2012 07:54:49 -0700 (PDT) Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by qmta01.westchester.pa.mail.comcast.net with comcast id pncR1j0051ei1Bg51qus4q; Wed, 22 Aug 2012 14:54:52 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta24.westchester.pa.mail.comcast.net with comcast id pquv1j00Q3ZTu2S3kquvlZ; Wed, 22 Aug 2012 14:54:56 +0000 Message-ID: <5034D6B4.9090100@alum.mit.edu> Date: Wed, 22 Aug 2012 08:55:16 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Roni Even References: <004a01cd7fb8$51919da0$f4b4d8e0$@gmail.com> <5033CFA2.50000@alum.mit.edu> <006901cd7fea$3e8b8c20$bba2a460$@gmail.com> <50340599.6000905@alum.mit.edu> <001f01cd802d$3748bd50$a5da37f0$@gmail.com> In-Reply-To: <001f01cd802d$3748bd50$a5da37f0$@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: clue@ietf.org Subject: Re: [clue] Notes and action items from 21-aug-2012 design team 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, 22 Aug 2012 14:54:53 -0000 On 8/22/12 2:13 AM, Roni Even wrote: > Paul, > I can see that it is feasible to define individual encodes this way. The > issue is that the use case for the encodes as stated in the framework is to > address physical constrains, when supporting multiple simultaneous streams. > If the idea was to use it for simulcast, it should state it. It was never > mentioned that the purpose is to support simulcast or any image control > functionality. If you want to use it to specify the image size by the > consumer it misses parameters currently available in the SDP image attribute Thanks Roni. I'm not trying to *sell* anything here. I just want everybody to have a common understanding of what we are doing. It's quite possible that my "shared understanding" comes from listening to people talk rather than to what is written. But we need to be agreeing on what is written. The next question then could be whether its important for the advertisement to be able to express an ability to simulcast a capture, and if so, for the receiver to be able to select more than one of the simulcast variants of that capture. Thanks, Paul > Roni > > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: 22 August, 2012 12:03 AM > To: Roni Even > Cc: clue@ietf.org > Subject: Re: [clue] Notes and action items from 21-aug-2012 design team > meeting > > On 8/21/12 6:13 PM, Roni Even wrote: >> Hi Paul, >> In number 4 this is not my action item. > > Well, I *tried* to give it to you. :-) > >> The current framework does not mention this usage for encoding groups >> and Paul Wity should point where it does. > > I'm not sure, but I *think* you are alone in not getting this understanding. > Maybe its implicit rather than explicit. But I was thinking if you are the > one who didn't get it you would best be able to say why. > > But maybe not. If its implicit then maybe someone who does infer it needs to > spell out what led to that inference. > >> I still think that we amp a capture ID. There may be more than one >> SSRC mapped to the same capture id > > If the configure message simply specified which captures it wanted, without > saying which encoding to use, then how is the decision about encoding made? > Does the sender choose? If the sender chooses, then what is the point of > putting encodings into the advertisement? > > And, if the recipient wants multiple encodings of the same capture, how > would it request that? > > Thanks, > Paul > >> I was making a general comment on the readability of the encoding >> group support in the framework >> >> >> >> Roni >> >> -----Original Message----- >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf >> Of Paul Kyzivat >> Sent: 21 August, 2012 8:13 PM >> To: clue@ietf.org >> Subject: [clue] Notes and action items from 21-aug-2012 design team >> meeting >> >> Thanks Roni. I was making notes but got pulled away to something else >> before I could finish. So I'll add to yours. >> >> >>> 4.Discussion about selecting encoding for a media capture. Is the >>> encoding only for defining physical limitation or do we use them also >>> for selecting for example a specific encoding in a simulcast for a >>> media capture. General question is if in a configuration you select a >>> media capture only or also a specific type of content and how you >>> advertise it (clarify the framework?) >> >> My impression of the discussion of this was broader. What I understood >> (from the documents and the discussion today) is that the >> configuration selects a number of *things* (for which we currently have no > name) to be received. >> Each of those things is a combination of one of the advertised >> captures and one of the advertised encodings. Its a simulcast if the >> same capture is selected multiple times - each in association with a > different encoding. >> There seemed to be widespread agreement about this. >> >> ** Roni took an action item to request specific clarifications in >> the framework to ensure all readers get the same understanding. >> >> >> >> This then means that the RTP header extension isn't conveying a > capture-id. >> Rather it is identifying one (or more) of these combinations of >> capture with encoding. >> >> If this is right, then we are lacking terminology for talking about >> this combination. So we need an addition to the framework to cover that > too. >> >>> I hope these are what we discussed >> >> We also discussed *briefly* discussed my two questions: >> >> - can CLUE *work* without a dynamic mapping of RTP stream to >> capture+encoding pair? (Hence the requirement for an RTP >> extension.) >> >> - if so, how severe are the negative consequences of doing so? >> >> What I got from the discussion was that we probably *could*, but only >> by restricting the topologies we support. And that would violate our >> requirements. (We didn't discuss which ones. But by my reading there >> is >> one: "REQMT-13: The solution MUST support both transcoding and >> switching approaches to providing multipoint conferences." >> >> Thanks, >> Paul >> >> >>> 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 Thu Aug 23 05:46: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 A492A21F84B6 for ; Thu, 23 Aug 2012 05:46:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZSWnycP1LLxT for ; Thu, 23 Aug 2012 05:46:38 -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 454B721F858E for ; Thu, 23 Aug 2012 05:46:38 -0700 (PDT) Received: by bkty7 with SMTP id y7so234192bkt.31 for ; Thu, 23 Aug 2012 05:46:37 -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:x-mailer:thread-index:content-language; bh=ltCe1hPfEqtzhDbWjSF2StrWlq8zPmndVzoGaLvZSjI=; b=DnL6mEsgWvcxvTEhIzMbOz15pFh129k7M+ThOrMwEAWUPSBdMTMlLYr/goUUehiYtx pvN8Z2t4V8NIX/jnTpwxVq41lJzJZzLT0T1mE5S5OOpC0dl37E0y817/7cMmukjb3eGO Bk9gYOYHGmloUAyWbgHBi171lxpXhp2+qUh6qZwaGTl9ImPrraW9tRx99g7kx5rMj3hD l2CoSAvkd6DOMnxctCZrNRVluQ/ZV+blyobsf+WV0a247foPJuzt5Cuq5W+XvK23CtXB CLph1Q6TJuM9dZZ82CB+5r4AsKTYqdW6MKuJ5FyYZ1ElIUiT9ogzlPkyWCCS2TqEZP52 YBZA== Received: by 10.205.127.77 with SMTP id gz13mr427748bkc.17.1345725997266; Thu, 23 Aug 2012 05:46:37 -0700 (PDT) Received: from RoniE ([109.64.216.128]) by mx.google.com with ESMTPS id hg13sm4571391bkc.7.2012.08.23.05.46.34 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 23 Aug 2012 05:46:36 -0700 (PDT) From: "Roni Even" To: "'Andy Pepperell'" References: <004a01cd7fb8$51919da0$f4b4d8e0$@gmail.com> <5033CFA2.50000@alum.mit.edu> <006901cd7fea$3e8b8c20$bba2a460$@gmail.com> In-Reply-To: Date: Thu, 23 Aug 2012 15:45:15 +0200 Message-ID: <002601cd8135$89425d10$9bc71730$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0027_01CD8146.4CCD9E10" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIm8qRg8ZZqP+83BAq7zn6qL3zShgJIWkJ2AZIxFQ8BcAqxf5aKLw0g Content-Language: en-us Cc: clue@ietf.org Subject: Re: [clue] Notes and action items from 21-aug-2012 design team 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, 23 Aug 2012 12:46:39 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0027_01CD8146.4CCD9E10 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Andy, I am looking at the simulcast support and what is not clear to me is in which topologies you see simulcast. I can understand a point to point where there is an offer and the receiver selects which stream it wants. (resolution, frame rate, bit rate and codec (useful for audio), but this is regular offer answer. The other topology is RTP mixer where the mixer may receives all simulcast streams from the sender and send each user a stream according to the receiver capability. Are there other use cases and what topology do you assume? Roni From: Andy Pepperell [mailto:apeppere@gmail.com] Sent: 22 August, 2012 9:26 AM To: Roni Even Cc: Paul Kyzivat; clue@ietf.org Subject: Re: [clue] Notes and action items from 21-aug-2012 design team meeting Hi Roni On Tue, Aug 21, 2012 at 11:13 PM, Roni Even wrote: Hi Paul, The current framework does not mention this usage for encoding groups and I was making a general comment on the readability of the encoding group support in the framework I think it was me that made the rash promise to ensure that the framework was clear on this point :) >From what I remember in the meeting what we said needing clarification was being able to instantiate a single capture into multiple encodings - to address this first, the framework talks about this in section 8, for instance: Every media capture is associated with an encoding group, which is used to instantiate that media capture into one or more encoded streams. and: If there are multiple individual encodings in the group, then a single media capture can be encoded into multiple different streams at the same time... and from section 9: For each media capture the consumer wants to receive, it configures one or more of the encodings in that capture's encoding group >[Roni] >I was making a general comment on the readability of the encoding group support in the framework I'm not sure how to answer this one, except perhaps asking you to make a more specific comment on the readability of the encoding group support in the framework... :) >Is the encoding only for defining physical limitation or do we use them also for selecting for example a specific encoding in a simulcast for a media capture. To attempt an answer on this one, yes, it's true that one usage of the encoding group system was to ensure that today's Telepresence endpoint devices which are typically formed of 2, 3, or 4 distinct regular endpoints with some additional control logic were well represented - specifically the likely constraint that only, say, the DSP resource on the device connected to the leftmost camera would be able to produce encodings of that camera's media capture. However, it would be wrong to say that the encoding group system is "only for defining physical limitation" as that's only one use, and we didn't want to be too prescriptive - a single-box software MCU might sensibly separate out its main and presentation encodings with separate encoding groups, or use this scheme to capture nuances of switched vs transcoded. >General question is if in a configuration you select a media capture only or also a specific type of content and how you advertise it (clarify the framework?) The configuration (consumer stream choice) mechanism is intended to allow the consumer to select both the set of capture encodings it wishes the provider to send to it, plus characteristics of those encodings such as maximum bandwidth / resolution etc. (all of which would be subject to SIP call level overall restrictions as conveyed by SDP, which would also define payload types etc. as now). > (clarify the framework?) I think it's a fair comment on the framework that, as compared to the level of detail and number of example cases relating to provider advertisements and encoding groups then the configuration / consumer stream choice side of things is perhaps under-represented in the document. This may be something worth addressing - additionally, the messaging / data model document will by necessity contain full details of all of these aspects. Regards, Andy ------=_NextPart_000_0027_01CD8146.4CCD9E10 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Andy,

I am looking at the simulcast support and what is not clear to me is = in which topologies you see simulcast.

I can understand a point to point where there is an offer and the = receiver selects which stream it wants. (resolution, frame rate, bit = rate and codec (useful for audio), but this is regular offer = answer.

The other topology is RTP mixer where the mixer may receives all = simulcast streams from the sender and send each user a stream according = to the receiver capability.

 

Are there other use cases and what topology do you = assume?

Roni

 

 

From:= = Andy Pepperell [mailto:apeppere@gmail.com]
Sent: 22 August, = 2012 9:26 AM
To: Roni Even
Cc: Paul Kyzivat; = clue@ietf.org
Subject: Re: [clue] Notes and action items from = 21-aug-2012 design team meeting

 

Hi Roni

On Tue, Aug 21, 2012 at 11:13 PM, Roni Even <ron.even.tlv@gmail.com> wrote:

Hi Paul,
The current framework does not mention = this usage for encoding groups and

 

I was making a general comment on the = readability of the encoding group
support in the = framework

 

I = think it was me that made the rash promise to ensure that the framework = was clear on this point :)

 

From what I remember in the meeting what we said = needing clarification was being able to instantiate a single capture = into multiple encodings - to address this first, the framework talks = about this in section 8, for instance:

Every media capture is associated with an encoding = group, which is used to instantiate that media capture into one or = more encoded streams.

and:

If there are multiple individual encodings in = the group, then a single media capture can be encoded into multiple = different streams at the same = time...

and from = section 9:

For = each media capture the consumer wants to receive, it configures one = or more of the encodings in that capture's encoding = group

 

>[Roni]

>I was making a general comment on the readability = of the encoding group support in the = framework

 

I'm not sure how to answer this one, except perhaps = asking you to make a more specific comment on the readability of the = encoding group support in the framework... = :)

 

>Is the encoding only for defining physical = limitation or do we use them also for selecting for example a = specific encoding in a simulcast for a = media

capture. 

 

To attempt an answer on this one, yes, it's true that = one usage of the encoding group system was to ensure that today's = Telepresence endpoint devices which are typically formed of 2, 3, or 4 = distinct regular endpoints with some additional control logic were well = represented - specifically the likely constraint that only, say, the DSP = resource on the device connected to the leftmost camera would be able to = produce encodings of that camera's media capture. However, it would be = wrong to say that the encoding group system is "only for defining = physical limitation" as that's only one use, and we didn't want to = be too prescriptive - a single-box software MCU might sensibly separate = out its main and presentation encodings with separate encoding groups, = or use this scheme to capture nuances of switched vs = transcoded.

 

>General question is if in a configuration you = select a media capture only or also a specific type of content and how = you advertise it (clarify the framework?)

 

The configuration (consumer stream choice) mechanism = is intended to allow the consumer to select both the set of capture = encodings it wishes the provider to send to it, plus characteristics of = those encodings such as maximum bandwidth / resolution etc. (all of = which would be subject to SIP call level overall restrictions as = conveyed by SDP, which would also define payload types etc. as = now).

 

>  (clarify the = framework?)

I think it's a = fair comment on the framework that, as compared to the level of detail = and number of example cases relating to provider advertisements and = encoding groups then the configuration / consumer stream choice side of = things is perhaps under-represented in the document. This may be = something worth addressing - additionally, the messaging / data model = document will by necessity contain full details of all of these = aspects.

 

Regards,

 

Andy

 

------=_NextPart_000_0027_01CD8146.4CCD9E10-- From espeberg@cisco.com Thu Aug 23 08:34: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 1168221F860D for ; Thu, 23 Aug 2012 08:34:21 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S7spz9Z3pNeY for ; Thu, 23 Aug 2012 08:34:19 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 6B10E21F858E for ; Thu, 23 Aug 2012 08:34:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=espeberg@cisco.com; l=22289; q=dns/txt; s=iport; t=1345736059; x=1346945659; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=lfBO5aFddLf3TdTGm6eoiOVMnIp/7T/p8jt4dKxiDrc=; b=LgCPQeUpYamph+mQr5He7agaJ3aiE8QXA2NoVMnFclk0jHDB+1AjMVBu IOeISRpakL6DCX1YaxBm6KLo2Ne6fekjEYUSdgT3wYeb61yGE7CRzQ64z pPLtRGwYQtQo8Qr+XtT6vJShxGuPKlboTUdxUGM8gjZFjkLX4uwwNqp+I A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFANhMNlCtJV2d/2dsb2JhbABFgkq4B4EHgiABAQEEEgEaTBACAQgOAwQBAQsWBwchERQJCAIEAQ0FCBqHXAMMmUeWbQ2JToolY4YxYAOUAYxggyCBZ4Jj X-IronPort-AV: E=Sophos;i="4.80,300,1344211200"; d="scan'208,217";a="114609443" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-6.cisco.com with ESMTP; 23 Aug 2012 15:34:15 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id q7NFYEvQ022403 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 23 Aug 2012 15:34:14 GMT Received: from xmb-rcd-x11.cisco.com ([169.254.1.118]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0298.004; Thu, 23 Aug 2012 10:34:14 -0500 From: "Espen Berger (espeberg)" To: Roni Even , "'Andy Pepperell'" Thread-Topic: [clue] Notes and action items from 21-aug-2012 design team meeting Thread-Index: AQHNf+IRHY0up2/Nn0inZTQ0ksejcpdlwsmAgAH8UYD//8NfUA== Date: Thu, 23 Aug 2012 15:34:13 +0000 Message-ID: References: <004a01cd7fb8$51919da0$f4b4d8e0$@gmail.com> <5033CFA2.50000@alum.mit.edu> <006901cd7fea$3e8b8c20$bba2a460$@gmail.com> <002601cd8135$89425d10$9bc71730$@gmail.com> In-Reply-To: <002601cd8135$89425d10$9bc71730$@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.147.112.147] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19132.005 x-tm-as-result: No--45.853500-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_E8F5F2C7B2623641BD9ABF0B622D726D0F4D99A8xmbrcdx11ciscoc_" MIME-Version: 1.0 Cc: "clue@ietf.org" Subject: Re: [clue] Notes and action items from 21-aug-2012 design team 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, 23 Aug 2012 15:34:21 -0000 --_000_E8F5F2C7B2623641BD9ABF0B622D726D0F4D99A8xmbrcdx11ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I think the RTP translator topology must be added, where a switching MCU ke= eps the SSRC from the originating media provider and rewrites the RTCP. My assumption is that the MCU does an aggregation based on the various cons= umer requests and do a configuration towards each provider of media. Cheers -Espen From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Ron= i Even Sent: 23. august 2012 15:45 To: 'Andy Pepperell' Cc: clue@ietf.org Subject: Re: [clue] Notes and action items from 21-aug-2012 design team mee= ting Hi Andy, I am looking at the simulcast support and what is not clear to me is in whi= ch topologies you see simulcast. I can understand a point to point where there is an offer and the receiver = selects which stream it wants. (resolution, frame rate, bit rate and codec = (useful for audio), but this is regular offer answer. The other topology is RTP mixer where the mixer may receives all simulcast = streams from the sender and send each user a stream according to the receiv= er capability. Are there other use cases and what topology do you assume? Roni From: Andy Pepperell [mailto:apeppere@gmail.com] Sent: 22 August, 2012 9:26 AM To: Roni Even Cc: Paul Kyzivat; clue@ietf.org Subject: Re: [clue] Notes and action items from 21-aug-2012 design team mee= ting Hi Roni On Tue, Aug 21, 2012 at 11:13 PM, Roni Even > wrote: Hi Paul, The current framework does not mention this usage for encoding groups and I was making a general comment on the readability of the encoding group support in the framework I think it was me that made the rash promise to ensure that the framework w= as clear on this point :) >From what I remember in the meeting what we said needing clarification was = being able to instantiate a single capture into multiple encodings - to add= ress this first, the framework talks about this in section 8, for instance: Every media capture is associated with an encoding group, which is used to = instantiate that media capture into one or more encoded streams. and: If there are multiple individual encodings in the group, then a single medi= a capture can be encoded into multiple different streams at the same time..= . and from section 9: For each media capture the consumer wants to receive, it configures one or = more of the encodings in that capture's encoding group >[Roni] >I was making a general comment on the readability of the encoding group su= pport in the framework I'm not sure how to answer this one, except perhaps asking you to make a mo= re specific comment on the readability of the encoding group support in the= framework... :) >Is the encoding only for defining physical limitation or do we use them al= so for selecting for example a specific encoding in a simulcast for a media capture. To attempt an answer on this one, yes, it's true that one usage of the enco= ding group system was to ensure that today's Telepresence endpoint devices = which are typically formed of 2, 3, or 4 distinct regular endpoints with so= me additional control logic were well represented - specifically the likely= constraint that only, say, the DSP resource on the device connected to the= leftmost camera would be able to produce encodings of that camera's media = capture. However, it would be wrong to say that the encoding group system i= s "only for defining physical limitation" as that's only one use, and we di= dn't want to be too prescriptive - a single-box software MCU might sensibly= separate out its main and presentation encodings with separate encoding gr= oups, or use this scheme to capture nuances of switched vs transcoded. >General question is if in a configuration you select a media capture only = or also a specific type of content and how you advertise it (clarify the fr= amework?) The configuration (consumer stream choice) mechanism is intended to allow t= he consumer to select both the set of capture encodings it wishes the provi= der to send to it, plus characteristics of those encodings such as maximum = bandwidth / resolution etc. (all of which would be subject to SIP call leve= l overall restrictions as conveyed by SDP, which would also define payload = types etc. as now). > (clarify the framework?) I think it's a fair comment on the framework that, as compared to the level= of detail and number of example cases relating to provider advertisements = and encoding groups then the configuration / consumer stream choice side of= things is perhaps under-represented in the document. This may be something= worth addressing - additionally, the messaging / data model document will = by necessity contain full details of all of these aspects. Regards, Andy --_000_E8F5F2C7B2623641BD9ABF0B622D726D0F4D99A8xmbrcdx11ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I think th= e RTP translator topology must be added, where a switching MCU keeps the SS= RC from the originating media provider and rewrites the RTCP.

 = ;

My assumpt= ion is that the MCU does an aggregation based on the various consumer reque= sts and do a configuration towards each provider of media.

 = ;

Cheers

 = ;

-Espen

 = ;

 = ;

From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Roni Even
Sent: 23. august 2012 15:45
To: 'Andy Pepperell'
Cc: clue@ietf.org
Subject: Re: [clue] Notes and action items from 21-aug-2012 design t= eam meeting

 

Hi Andy,

I am looki= ng at the simulcast support and what is not clear to me is in which topolog= ies you see simulcast.

I can unde= rstand a point to point where there is an offer and the receiver selects wh= ich stream it wants. (resolution, frame rate, bit rate and codec (useful for audio), but this is regular offer answer.

The other = topology is RTP mixer where the mixer may receives all simulcast streams fr= om the sender and send each user a stream according to the receiver capability.

 = ;

Are there = other use cases and what topology do you assume?

Roni<= /o:p>

 = ;

 = ;

From: Andy Pepperell [mailto:apeppere@gmail.com]<= /a>
Sent: 22 August, 2012 9:26 AM
To: Roni Even
Cc: Paul Kyzivat; clue@ietf.org=
Subject: Re: [clue] Notes and action items from 21-aug-2012 design t= eam meeting

 

= Hi Roni

On Tue, Aug 21, 2012 at 11:13 P= M, Roni Even <ron.even.tlv@gmail.com> wrote:

Hi Paul,
The current framework does not mention this usage for encoding groups and

 

= I was making a general comment on the readability of the encoding group
support in the framework

 

I think it was me that made the= rash promise to ensure that the framework was clear on this point :)<= /o:p>

 

From what I remember in the mee= ting what we said needing clarification was being able to instantiate a sin= gle capture into multiple encodings - to address this first, the framework = talks about this in section 8, for instance:

Every media capture is assoc= iated with an encoding group, which is used to instantiate that media = capture into one or more encoded streams.

and:

If there are multiple i= ndividual encodings in the group, then a single media capture can be e= ncoded into multiple different streams at the same time...

and from section 9:<= /span>

For each media capture the c= onsumer wants to receive, it configures one or more of the encodings i= n that capture's encoding group<= /span>

 

>[Roni]

>I was making a general comm= ent on the readability of the encoding group support in the framework<= o:p>

 

I'm not sure how to answer this= one, except perhaps asking you to make a more specific comment on the read= ability of the encoding group support in the framework... :)

 

>Is the encoding only f= or defining physical limitation or do we use them also for selecting f= or example a specific encoding in a simulcast for a media=

capture. 

 

To attempt an answer on this on= e, yes, it's true that one usage of the encoding group system was to ensure= that today's Telepresence endpoint devices which are typically formed of 2= , 3, or 4 distinct regular endpoints with some additional control logic were well represented - specifically th= e likely constraint that only, say, the DSP resource on the device connecte= d to the leftmost camera would be able to produce encodings of that camera'= s media capture. However, it would be wrong to say that the encoding group system is "only for defining = physical limitation" as that's only one use, and we didn't want to be = too prescriptive - a single-box software MCU might sensibly separate out it= s main and presentation encodings with separate encoding groups, or use this scheme to capture nuances of switched vs tran= scoded.

 

>General question is if in a= configuration you select a media capture only or also a specific type of c= ontent and how you advertise it (clarify the framework?)<= /p>

 

The configuration (consumer str= eam choice) mechanism is intended to allow the consumer to select both the = set of capture encodings it wishes the provider to send to it, plus charact= eristics of those encodings such as maximum bandwidth / resolution etc. (all of which would be subject to SIP = call level overall restrictions as conveyed by SDP, which would also define= payload types etc. as now).

 

>  (clarify the fr= amework?)

I think it's a fair comment on = the framework that, as compared to the level of detail and number of exampl= e cases relating to provider advertisements and encoding groups then the co= nfiguration / consumer stream choice side of things is perhaps under-represented in the document. This may be s= omething worth addressing - additionally, the messaging / data model docume= nt will by necessity contain full details of all of these aspects.

 

Regards,

 

Andy

 

--_000_E8F5F2C7B2623641BD9ABF0B622D726D0F4D99A8xmbrcdx11ciscoc_-- From ron.even.tlv@gmail.com Thu Aug 23 11:55: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 CB06921F8653 for ; Thu, 23 Aug 2012 11:55:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d4XeM4uJNR6V for ; Thu, 23 Aug 2012 11:55:06 -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 EDC7221F8652 for ; Thu, 23 Aug 2012 11:55:05 -0700 (PDT) Received: by wicr5 with SMTP id r5so5291wic.13 for ; Thu, 23 Aug 2012 11:55:05 -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:x-mailer:thread-index:content-language; bh=jNPNL0xIzyldynKgweZZ3fCrq+VNRTmBlHwA2AjcFOU=; b=mcralKKRJldjRoUxfohsM6OtDraEWPUliIsQviFQ3uoKve4Ah6X4Qfi05LjJ9uCHRt umH2Vun4JyGFUlNLMBlS0ApU15VmxvYBGbSzXLCKhyIrLvU2CBrTYXr8WHzLqev1tp2Y UnwVpvd0mz9hnd7oJtYunQM2LEUBBGry8iybIJ22utp+gZqxk2SOiFuQkjMGbDwPPKj5 VJH4GBfhgnq9X1ghOD18qB+/p0P9LDnK2wIraClkoT5gzF4fBgYVBW/shsr7OCkrkjlp 6DAi/RlWujpxVqbA7GjWWCoZoCSj1u3pI5Ubm7Qlgw5yDooXVg4Xx9n7qLX4WB5UQWOB fThQ== Received: by 10.180.98.138 with SMTP id ei10mr6350230wib.1.1345748104912; Thu, 23 Aug 2012 11:55:04 -0700 (PDT) Received: from RoniE ([109.64.233.150]) by mx.google.com with ESMTPS id d10sm5484wiy.0.2012.08.23.11.55.01 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 23 Aug 2012 11:55:03 -0700 (PDT) From: "Roni Even" To: "'Espen Berger \(espeberg\)'" , "'Andy Pepperell'" References: <004a01cd7fb8$51919da0$f4b4d8e0$@gmail.com> <5033CFA2.50000@alum.mit.edu> <006901cd7fea$3e8b8c20$bba2a460$@gmail.com> <002601cd8135$89425d10$9bc71730$@gmail.com> In-Reply-To: Date: Thu, 23 Aug 2012 21:53:43 +0200 Message-ID: <005401cd8169$02adb4a0$08091de0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0055_01CD8179.C638CE90" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIm8qRg8ZZqP+83BAq7zn6qL3zShgJIWkJ2AZIxFQ8BcAqxfwJMUXlzAo4v9raWY8OTwA== Content-Language: en-us Cc: clue@ietf.org Subject: Re: [clue] Notes and action items from 21-aug-2012 design team 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, 23 Aug 2012 18:55:08 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0055_01CD8179.C638CE90 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Eapen, I think that there may be a problem with a translator for the multicast since if the translator will forward only part of the multicast streams it will receive RTCP RR only for this art and may think that the other were lost Roni From: Espen Berger (espeberg) [mailto:espeberg@cisco.com] Sent: 23 August, 2012 5:34 PM To: Roni Even; 'Andy Pepperell' Cc: clue@ietf.org Subject: RE: [clue] Notes and action items from 21-aug-2012 design team meeting I think the RTP translator topology must be added, where a switching MCU keeps the SSRC from the originating media provider and rewrites the RTCP. My assumption is that the MCU does an aggregation based on the various consumer requests and do a configuration towards each provider of media. Cheers -Espen From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Roni Even Sent: 23. august 2012 15:45 To: 'Andy Pepperell' Cc: clue@ietf.org Subject: Re: [clue] Notes and action items from 21-aug-2012 design team meeting Hi Andy, I am looking at the simulcast support and what is not clear to me is in which topologies you see simulcast. I can understand a point to point where there is an offer and the receiver selects which stream it wants. (resolution, frame rate, bit rate and codec (useful for audio), but this is regular offer answer. The other topology is RTP mixer where the mixer may receives all simulcast streams from the sender and send each user a stream according to the receiver capability. Are there other use cases and what topology do you assume? Roni From: Andy Pepperell [mailto:apeppere@gmail.com] Sent: 22 August, 2012 9:26 AM To: Roni Even Cc: Paul Kyzivat; clue@ietf.org Subject: Re: [clue] Notes and action items from 21-aug-2012 design team meeting Hi Roni On Tue, Aug 21, 2012 at 11:13 PM, Roni Even wrote: Hi Paul, The current framework does not mention this usage for encoding groups and I was making a general comment on the readability of the encoding group support in the framework I think it was me that made the rash promise to ensure that the framework was clear on this point :) >From what I remember in the meeting what we said needing clarification was being able to instantiate a single capture into multiple encodings - to address this first, the framework talks about this in section 8, for instance: Every media capture is associated with an encoding group, which is used to instantiate that media capture into one or more encoded streams. and: If there are multiple individual encodings in the group, then a single media capture can be encoded into multiple different streams at the same time... and from section 9: For each media capture the consumer wants to receive, it configures one or more of the encodings in that capture's encoding group >[Roni] >I was making a general comment on the readability of the encoding group support in the framework I'm not sure how to answer this one, except perhaps asking you to make a more specific comment on the readability of the encoding group support in the framework... :) >Is the encoding only for defining physical limitation or do we use them also for selecting for example a specific encoding in a simulcast for a media capture. To attempt an answer on this one, yes, it's true that one usage of the encoding group system was to ensure that today's Telepresence endpoint devices which are typically formed of 2, 3, or 4 distinct regular endpoints with some additional control logic were well represented - specifically the likely constraint that only, say, the DSP resource on the device connected to the leftmost camera would be able to produce encodings of that camera's media capture. However, it would be wrong to say that the encoding group system is "only for defining physical limitation" as that's only one use, and we didn't want to be too prescriptive - a single-box software MCU might sensibly separate out its main and presentation encodings with separate encoding groups, or use this scheme to capture nuances of switched vs transcoded. >General question is if in a configuration you select a media capture only or also a specific type of content and how you advertise it (clarify the framework?) The configuration (consumer stream choice) mechanism is intended to allow the consumer to select both the set of capture encodings it wishes the provider to send to it, plus characteristics of those encodings such as maximum bandwidth / resolution etc. (all of which would be subject to SIP call level overall restrictions as conveyed by SDP, which would also define payload types etc. as now). > (clarify the framework?) I think it's a fair comment on the framework that, as compared to the level of detail and number of example cases relating to provider advertisements and encoding groups then the configuration / consumer stream choice side of things is perhaps under-represented in the document. This may be something worth addressing - additionally, the messaging / data model document will by necessity contain full details of all of these aspects. Regards, Andy ------=_NextPart_000_0055_01CD8179.C638CE90 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Eapen,

I think that there may be a problem with a translator for the = multicast since if the translator will forward only part of the = multicast streams it will receive RTCP RR only for this art and may = think that the other were lost

Roni

 

From:= = Espen Berger (espeberg) [mailto:espeberg@cisco.com]
Sent: 23 = August, 2012 5:34 PM
To: Roni Even; 'Andy = Pepperell'
Cc: clue@ietf.org
Subject: RE: [clue] = Notes and action items from 21-aug-2012 design team = meeting

 

I think the RTP translator topology must be added, where a switching = MCU keeps the SSRC from the originating media provider and rewrites the = RTCP.

 

My assumption is that the MCU does an aggregation based on the = various consumer requests and do a configuration towards each provider = of media.

 

Cheers

 

-Espen

 

 

From:= = clue-bounces@ietf.org [mailto:clue-bounces@ietf.= org] On Behalf Of Roni Even
Sent: 23. august 2012 = 15:45
To: 'Andy Pepperell'
Cc: clue@ietf.org
Subject: Re: = [clue] Notes and action items from 21-aug-2012 design team = meeting

 

Hi Andy,

I am looking at the simulcast support and what is not clear to me is = in which topologies you see simulcast.

I can understand a point to point where there is an offer and the = receiver selects which stream it wants. (resolution, frame rate, bit = rate and codec (useful for audio), but this is regular offer = answer.

The other topology is RTP mixer where the mixer may receives all = simulcast streams from the sender and send each user a stream according = to the receiver capability.

 

Are there other use cases and what topology do you = assume?

Roni

 

 

From:= = Andy Pepperell [mailto:apeppere@gmail.com]
Sent: 22 August, 2012 9:26 AM
To: Roni = Even
Cc: Paul Kyzivat; clue@ietf.org
Subject: Re: = [clue] Notes and action items from 21-aug-2012 design team = meeting

 

Hi Roni

On Tue, Aug 21, 2012 at 11:13 PM, Roni Even <ron.even.tlv@gmail.com> wrote:

Hi Paul,
The current framework does not mention = this usage for encoding groups and

 

I was making a = general comment on the readability of the encoding group
support in = the framework

 

I = think it was me that made the rash promise to ensure that the framework = was clear on this point :)

 

From what I remember in the meeting what we said = needing clarification was being able to instantiate a single capture = into multiple encodings - to address this first, the framework talks = about this in section 8, for instance:

Every media capture is associated with an encoding = group, which is used to instantiate that media capture into one or = more encoded streams.

and:

If there are multiple individual encodings in = the group, then a single media capture can be encoded into multiple = different streams at the same = time...

and from = section 9:

For = each media capture the consumer wants to receive, it configures one = or more of the encodings in that capture's encoding = group

 

>[Roni]

>I was making a general comment on the readability = of the encoding group support in the = framework

 

I'm not sure how to answer this one, except perhaps = asking you to make a more specific comment on the readability of the = encoding group support in the framework... = :)

 

>Is the encoding only for defining physical = limitation or do we use them also for selecting for example a = specific encoding in a simulcast for a = media

capture. 

 

To attempt an answer on this one, yes, it's true that = one usage of the encoding group system was to ensure that today's = Telepresence endpoint devices which are typically formed of 2, 3, or 4 = distinct regular endpoints with some additional control logic were well = represented - specifically the likely constraint that only, say, the DSP = resource on the device connected to the leftmost camera would be able to = produce encodings of that camera's media capture. However, it would be = wrong to say that the encoding group system is "only for defining = physical limitation" as that's only one use, and we didn't want to = be too prescriptive - a single-box software MCU might sensibly separate = out its main and presentation encodings with separate encoding groups, = or use this scheme to capture nuances of switched vs = transcoded.

 

>General question is if in a configuration you = select a media capture only or also a specific type of content and how = you advertise it (clarify the framework?)

 

The configuration (consumer stream choice) mechanism = is intended to allow the consumer to select both the set of capture = encodings it wishes the provider to send to it, plus characteristics of = those encodings such as maximum bandwidth / resolution etc. (all of = which would be subject to SIP call level overall restrictions as = conveyed by SDP, which would also define payload types etc. as = now).

 

>  (clarify the = framework?)

I think it's a = fair comment on the framework that, as compared to the level of detail = and number of example cases relating to provider advertisements and = encoding groups then the configuration / consumer stream choice side of = things is perhaps under-represented in the document. This may be = something worth addressing - additionally, the messaging / data model = document will by necessity contain full details of all of these = aspects.

 

Regards,

 

Andy

 

------=_NextPart_000_0055_01CD8179.C638CE90-- From ron.even.tlv@gmail.com Thu Aug 23 13: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 9307321F8643 for ; Thu, 23 Aug 2012 13:45:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xVC4LNHMPbFP for ; Thu, 23 Aug 2012 13:45:23 -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 8EDF921F8606 for ; Thu, 23 Aug 2012 13:45:21 -0700 (PDT) Received: by wibhr14 with SMTP id hr14so86043wib.13 for ; Thu, 23 Aug 2012 13:45:20 -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:x-mailer:thread-index:content-language; bh=Hlmva5uJg44asa+n1Le6wto8qiZ3+7BU7BBPq/iRF8c=; b=qKNyWkIojWU7uWwNMCQvZSuqVYnyHkdwtGqAFrvagueDv2AHze07IkZnUzZxS5kEyE XPGV/qspdAOTZm+B6z9lyw3Xog+Syv1UvA/MD3jW0k3quQs3i88yDDBkdKUut77I/4Kp yxlMlOXn1YM0HLOdxNmhoUFuTaWJroxwWnCKe5hNdXKTLUyQ+uiwkqYzqjfeHx4kN/1w FPIxAdFTYNZVgL1FRbxmH0zpTAbdMUL1N6w9AHNLtw9vzbsXPkq5DcLS8yaydQ34HhOj NrqtENyKnczudoSCHlAgjdD9SRBq/CsSbI6rIxi9q+8L56LWFU6RHYnPaLFHi8Oxd1QB ut/w== Received: by 10.216.214.85 with SMTP id b63mr1480928wep.154.1345754720533; Thu, 23 Aug 2012 13:45:20 -0700 (PDT) Received: from RoniE ([109.64.233.150]) by mx.google.com with ESMTPS id t7sm697148wix.6.2012.08.23.13.45.17 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 23 Aug 2012 13:45:19 -0700 (PDT) From: "Roni Even" To: "'Espen Berger \(espeberg\)'" , "'Andy Pepperell'" References: <004a01cd7fb8$51919da0$f4b4d8e0$@gmail.com> <5033CFA2.50000@alum.mit.edu> <006901cd7fea$3e8b8c20$bba2a460$@gmail.com> <002601cd8135$89425d10$9bc71730$@gmail.com> In-Reply-To: Date: Thu, 23 Aug 2012 23:43:59 +0200 Message-ID: <006201cd8178$69e36020$3daa2060$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0063_01CD8189.2D6C3020" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIm8qRg8ZZqP+83BAq7zn6qL3zShgJIWkJ2AZIxFQ8BcAqxfwJMUXlzAo4v9raWY+KzMA== Content-Language: en-us Cc: clue@ietf.org Subject: Re: [clue] Notes and action items from 21-aug-2012 design team 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, 23 Aug 2012 20:45:25 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0063_01CD8189.2D6C3020 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Espen, Please look at http://tools.ietf.org/html/draft-westerlund-avtcore-rtp-simulcast-01 Roni From: Espen Berger (espeberg) [mailto:espeberg@cisco.com] Sent: 23 August, 2012 5:34 PM To: Roni Even; 'Andy Pepperell' Cc: clue@ietf.org Subject: RE: [clue] Notes and action items from 21-aug-2012 design team meeting I think the RTP translator topology must be added, where a switching MCU keeps the SSRC from the originating media provider and rewrites the RTCP. My assumption is that the MCU does an aggregation based on the various consumer requests and do a configuration towards each provider of media. Cheers -Espen From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Roni Even Sent: 23. august 2012 15:45 To: 'Andy Pepperell' Cc: clue@ietf.org Subject: Re: [clue] Notes and action items from 21-aug-2012 design team meeting Hi Andy, I am looking at the simulcast support and what is not clear to me is in which topologies you see simulcast. I can understand a point to point where there is an offer and the receiver selects which stream it wants. (resolution, frame rate, bit rate and codec (useful for audio), but this is regular offer answer. The other topology is RTP mixer where the mixer may receives all simulcast streams from the sender and send each user a stream according to the receiver capability. Are there other use cases and what topology do you assume? Roni From: Andy Pepperell [mailto:apeppere@gmail.com] Sent: 22 August, 2012 9:26 AM To: Roni Even Cc: Paul Kyzivat; clue@ietf.org Subject: Re: [clue] Notes and action items from 21-aug-2012 design team meeting Hi Roni On Tue, Aug 21, 2012 at 11:13 PM, Roni Even wrote: Hi Paul, The current framework does not mention this usage for encoding groups and I was making a general comment on the readability of the encoding group support in the framework I think it was me that made the rash promise to ensure that the framework was clear on this point :) >From what I remember in the meeting what we said needing clarification was being able to instantiate a single capture into multiple encodings - to address this first, the framework talks about this in section 8, for instance: Every media capture is associated with an encoding group, which is used to instantiate that media capture into one or more encoded streams. and: If there are multiple individual encodings in the group, then a single media capture can be encoded into multiple different streams at the same time... and from section 9: For each media capture the consumer wants to receive, it configures one or more of the encodings in that capture's encoding group >[Roni] >I was making a general comment on the readability of the encoding group support in the framework I'm not sure how to answer this one, except perhaps asking you to make a more specific comment on the readability of the encoding group support in the framework... :) >Is the encoding only for defining physical limitation or do we use them also for selecting for example a specific encoding in a simulcast for a media capture. To attempt an answer on this one, yes, it's true that one usage of the encoding group system was to ensure that today's Telepresence endpoint devices which are typically formed of 2, 3, or 4 distinct regular endpoints with some additional control logic were well represented - specifically the likely constraint that only, say, the DSP resource on the device connected to the leftmost camera would be able to produce encodings of that camera's media capture. However, it would be wrong to say that the encoding group system is "only for defining physical limitation" as that's only one use, and we didn't want to be too prescriptive - a single-box software MCU might sensibly separate out its main and presentation encodings with separate encoding groups, or use this scheme to capture nuances of switched vs transcoded. >General question is if in a configuration you select a media capture only or also a specific type of content and how you advertise it (clarify the framework?) The configuration (consumer stream choice) mechanism is intended to allow the consumer to select both the set of capture encodings it wishes the provider to send to it, plus characteristics of those encodings such as maximum bandwidth / resolution etc. (all of which would be subject to SIP call level overall restrictions as conveyed by SDP, which would also define payload types etc. as now). > (clarify the framework?) I think it's a fair comment on the framework that, as compared to the level of detail and number of example cases relating to provider advertisements and encoding groups then the configuration / consumer stream choice side of things is perhaps under-represented in the document. This may be something worth addressing - additionally, the messaging / data model document will by necessity contain full details of all of these aspects. Regards, Andy ------=_NextPart_000_0063_01CD8189.2D6C3020 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Espen,

Please look at http://tools.ietf.org/html/draft-westerlund-avtcore-rtp-simulcast-01=

Roni

 

From:= = Espen Berger (espeberg) [mailto:espeberg@cisco.com]
Sent: 23 = August, 2012 5:34 PM
To: Roni Even; 'Andy = Pepperell'
Cc: clue@ietf.org
Subject: RE: [clue] = Notes and action items from 21-aug-2012 design team = meeting

 

I think the RTP translator topology must be added, where a switching = MCU keeps the SSRC from the originating media provider and rewrites the = RTCP.

 

My assumption is that the MCU does an aggregation based on the = various consumer requests and do a configuration towards each provider = of media.

 

Cheers

 

-Espen

 

 

From:= = clue-bounces@ietf.org [mailto:clue-bounces@ietf.= org] On Behalf Of Roni Even
Sent: 23. august 2012 = 15:45
To: 'Andy Pepperell'
Cc: clue@ietf.org
Subject: Re: = [clue] Notes and action items from 21-aug-2012 design team = meeting

 

Hi Andy,

I am looking at the simulcast support and what is not clear to me is = in which topologies you see simulcast.

I can understand a point to point where there is an offer and the = receiver selects which stream it wants. (resolution, frame rate, bit = rate and codec (useful for audio), but this is regular offer = answer.

The other topology is RTP mixer where the mixer may receives all = simulcast streams from the sender and send each user a stream according = to the receiver capability.

 

Are there other use cases and what topology do you = assume?

Roni

 

 

From:= = Andy Pepperell [mailto:apeppere@gmail.com]
Sent: 22 August, 2012 9:26 AM
To: Roni = Even
Cc: Paul Kyzivat; clue@ietf.org
Subject: Re: = [clue] Notes and action items from 21-aug-2012 design team = meeting

 

Hi Roni

On Tue, Aug 21, 2012 at 11:13 PM, Roni Even <ron.even.tlv@gmail.com> wrote:

Hi Paul,
The current framework does not mention = this usage for encoding groups and

 

I was making a = general comment on the readability of the encoding group
support in = the framework

 

I = think it was me that made the rash promise to ensure that the framework = was clear on this point :)

 

From what I remember in the meeting what we said = needing clarification was being able to instantiate a single capture = into multiple encodings - to address this first, the framework talks = about this in section 8, for instance:

Every media capture is associated with an encoding = group, which is used to instantiate that media capture into one or = more encoded streams.

and:

If there are multiple individual encodings in = the group, then a single media capture can be encoded into multiple = different streams at the same = time...

and from = section 9:

For = each media capture the consumer wants to receive, it configures one = or more of the encodings in that capture's encoding = group

 

>[Roni]

>I was making a general comment on the readability = of the encoding group support in the = framework

 

I'm not sure how to answer this one, except perhaps = asking you to make a more specific comment on the readability of the = encoding group support in the framework... = :)

 

>Is the encoding only for defining physical = limitation or do we use them also for selecting for example a = specific encoding in a simulcast for a = media

capture. 

 

To attempt an answer on this one, yes, it's true that = one usage of the encoding group system was to ensure that today's = Telepresence endpoint devices which are typically formed of 2, 3, or 4 = distinct regular endpoints with some additional control logic were well = represented - specifically the likely constraint that only, say, the DSP = resource on the device connected to the leftmost camera would be able to = produce encodings of that camera's media capture. However, it would be = wrong to say that the encoding group system is "only for defining = physical limitation" as that's only one use, and we didn't want to = be too prescriptive - a single-box software MCU might sensibly separate = out its main and presentation encodings with separate encoding groups, = or use this scheme to capture nuances of switched vs = transcoded.

 

>General question is if in a configuration you = select a media capture only or also a specific type of content and how = you advertise it (clarify the framework?)

 

The configuration (consumer stream choice) mechanism = is intended to allow the consumer to select both the set of capture = encodings it wishes the provider to send to it, plus characteristics of = those encodings such as maximum bandwidth / resolution etc. (all of = which would be subject to SIP call level overall restrictions as = conveyed by SDP, which would also define payload types etc. as = now).

 

>  (clarify the = framework?)

I think it's a = fair comment on the framework that, as compared to the level of detail = and number of example cases relating to provider advertisements and = encoding groups then the configuration / consumer stream choice side of = things is perhaps under-represented in the document. This may be = something worth addressing - additionally, the messaging / data model = document will by necessity contain full details of all of these = aspects.

 

Regards,

 

Andy

 

------=_NextPart_000_0063_01CD8189.2D6C3020-- From espeberg@cisco.com Fri Aug 24 01:15: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 BF8E421F86D0 for ; Fri, 24 Aug 2012 01:15:24 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I0MeT9AOwd5R for ; Fri, 24 Aug 2012 01:15:20 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 330DD21F86C9 for ; Fri, 24 Aug 2012 01:15:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=espeberg@cisco.com; l=27399; q=dns/txt; s=iport; t=1345796120; x=1347005720; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=MCKlnQygVVWZnRI5qAEt6yMQnMzYAqaePkkvZX/owlg=; b=MGp7Xd73MJ+0g5ls7pDupjn/xP4VuJBIjGQnqVPjE9kuyKYKkPZDlW6C Y7swJ8kVh5jEu8BzEYCAFWtKhlVe1DubL4NEprNOv3u4XUJ1VQ9Yza1Ap a+3AiKOtrTUoAVAfcZyPqL3uuPawg/gjYI6JU3QonfDwLvcuLRF2SgOMp M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAA03N1CtJXG+/2dsb2JhbABFgkqvPQGITIEHgiABAQECAhIBGkwQAgEIDgMEAQELFgcHIREUCQgCBAENBQgBGYdcAwwLmTWWQQ2JToolY4YxYAOUAYJniXmDIIFngmM X-IronPort-AV: E=Sophos;i="4.80,302,1344211200"; d="scan'208,217";a="114863076" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-2.cisco.com with ESMTP; 24 Aug 2012 08:15:19 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id q7O8FJ3l028689 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 24 Aug 2012 08:15:19 GMT Received: from xmb-rcd-x11.cisco.com ([169.254.1.118]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0298.004; Fri, 24 Aug 2012 03:15:18 -0500 From: "Espen Berger (espeberg)" To: Roni Even , "'Andy Pepperell'" Thread-Topic: [clue] Notes and action items from 21-aug-2012 design team meeting Thread-Index: AQHNf+IRHY0up2/Nn0inZTQ0ksejcpdlwsmAgAH8UYD//8NfUIAAwmKAgABYDPA= Date: Fri, 24 Aug 2012 08:15:18 +0000 Message-ID: References: <004a01cd7fb8$51919da0$f4b4d8e0$@gmail.com> <5033CFA2.50000@alum.mit.edu> <006901cd7fea$3e8b8c20$bba2a460$@gmail.com> <002601cd8135$89425d10$9bc71730$@gmail.com> <006201cd8178$69e36020$3daa2060$@gmail.com> In-Reply-To: <006201cd8178$69e36020$3daa2060$@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.147.112.147] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19134.004 x-tm-as-result: No--57.465300-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_E8F5F2C7B2623641BD9ABF0B622D726D0F4D9C7Cxmbrcdx11ciscoc_" MIME-Version: 1.0 Cc: "clue@ietf.org" Subject: Re: [clue] Notes and action items from 21-aug-2012 design team 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: Fri, 24 Aug 2012 08:15:25 -0000 --_000_E8F5F2C7B2623641BD9ABF0B622D726D0F4D9C7Cxmbrcdx11ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Roni The reference to RTP translator topology was incorrect, I was thinking abou= t the 'Selective Forwarding Switch' topology that Magnus presented during t= he June interim meeting. The presentation has addition topologies that are = not yet in the RFC5115 RTP topology document, so hopefully someone will upd= ate it. Regarding you comment on RTCP RR; A selective forwarding switch can keep tr= ack of streams sent and received for each RTP session and rewrite all RTCP = SR/RR to make sure that RTCP information is correct for each RTP session. T= he topology will result in source disappearing and reappearing again based = on the MCU policies, which must be understood and handled in terms of the v= arious RTP mechanisms. Cheers -Espen [rtp-topology] - http://www.ietf.org/proceedings/interim/2012/06/07/clue/s= lides/slides-interim-2012-clue-2-6.pdf From: Roni Even [mailto:ron.even.tlv@gmail.com] Sent: 23. august 2012 23:44 To: Espen Berger (espeberg); 'Andy Pepperell' Cc: clue@ietf.org Subject: RE: [clue] Notes and action items from 21-aug-2012 design team mee= ting Hi Espen, Please look at http://tools.ietf.org/html/draft-westerlund-avtcore-rtp-simu= lcast-01 Roni From: Espen Berger (espeberg) [mailto:espeberg@cisco.com] Sent: 23 August, 2012 5:34 PM To: Roni Even; 'Andy Pepperell' Cc: clue@ietf.org Subject: RE: [clue] Notes and action items from 21-aug-2012 design team mee= ting I think the RTP translator topology must be added, where a switching MCU ke= eps the SSRC from the originating media provider and rewrites the RTCP. My assumption is that the MCU does an aggregation based on the various cons= umer requests and do a configuration towards each provider of media. Cheers -Espen From: clue-bounces@ietf.org [mailto:clue-boun= ces@ietf.org] On Behalf Of Roni Even Sent: 23. august 2012 15:45 To: 'Andy Pepperell' Cc: clue@ietf.org Subject: Re: [clue] Notes and action items from 21-aug-2012 design team mee= ting Hi Andy, I am looking at the simulcast support and what is not clear to me is in whi= ch topologies you see simulcast. I can understand a point to point where there is an offer and the receiver = selects which stream it wants. (resolution, frame rate, bit rate and codec = (useful for audio), but this is regular offer answer. The other topology is RTP mixer where the mixer may receives all simulcast = streams from the sender and send each user a stream according to the receiv= er capability. Are there other use cases and what topology do you assume? Roni From: Andy Pepperell [mailto:apeppere@gmail.com] Sent: 22 August, 2012 9:26 AM To: Roni Even Cc: Paul Kyzivat; clue@ietf.org Subject: Re: [clue] Notes and action items from 21-aug-2012 design team mee= ting Hi Roni On Tue, Aug 21, 2012 at 11:13 PM, Roni Even > wrote: Hi Paul, The current framework does not mention this usage for encoding groups and I was making a general comment on the readability of the encoding group support in the framework I think it was me that made the rash promise to ensure that the framework w= as clear on this point :) >From what I remember in the meeting what we said needing clarification was = being able to instantiate a single capture into multiple encodings - to add= ress this first, the framework talks about this in section 8, for instance: Every media capture is associated with an encoding group, which is used to = instantiate that media capture into one or more encoded streams. and: If there are multiple individual encodings in the group, then a single medi= a capture can be encoded into multiple different streams at the same time..= . and from section 9: For each media capture the consumer wants to receive, it configures one or = more of the encodings in that capture's encoding group >[Roni] >I was making a general comment on the readability of the encoding group su= pport in the framework I'm not sure how to answer this one, except perhaps asking you to make a mo= re specific comment on the readability of the encoding group support in the= framework... :) >Is the encoding only for defining physical limitation or do we use them al= so for selecting for example a specific encoding in a simulcast for a media capture. To attempt an answer on this one, yes, it's true that one usage of the enco= ding group system was to ensure that today's Telepresence endpoint devices = which are typically formed of 2, 3, or 4 distinct regular endpoints with so= me additional control logic were well represented - specifically the likely= constraint that only, say, the DSP resource on the device connected to the= leftmost camera would be able to produce encodings of that camera's media = capture. However, it would be wrong to say that the encoding group system i= s "only for defining physical limitation" as that's only one use, and we di= dn't want to be too prescriptive - a single-box software MCU might sensibly= separate out its main and presentation encodings with separate encoding gr= oups, or use this scheme to capture nuances of switched vs transcoded. >General question is if in a configuration you select a media capture only = or also a specific type of content and how you advertise it (clarify the fr= amework?) The configuration (consumer stream choice) mechanism is intended to allow t= he consumer to select both the set of capture encodings it wishes the provi= der to send to it, plus characteristics of those encodings such as maximum = bandwidth / resolution etc. (all of which would be subject to SIP call leve= l overall restrictions as conveyed by SDP, which would also define payload = types etc. as now). > (clarify the framework?) I think it's a fair comment on the framework that, as compared to the level= of detail and number of example cases relating to provider advertisements = and encoding groups then the configuration / consumer stream choice side of= things is perhaps under-represented in the document. This may be something= worth addressing - additionally, the messaging / data model document will = by necessity contain full details of all of these aspects. Regards, Andy --_000_E8F5F2C7B2623641BD9ABF0B622D726D0F4D9C7Cxmbrcdx11ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Roni=

 <= /p>

The refere= nce to RTP translator topology was incorrect, I was thinking about the R= 16;Selective Forwarding Switch’ topology that Magnus presented during the June interim meeting. The presentation has addition topologies that ar= e not yet in the RFC5115 RTP topology document, so hopefully someone will u= pdate it.

 = ;

Regarding = you comment on RTCP RR; A selective forwarding switch can keep track of str= eams sent and received for each RTP session and rewrite all RTCP SR/RR to make sure that RTCP information is correct for each RTP sess= ion. The topology will result in source disappearing and reappearing again = based on the MCU policies, which must be understood and handled in terms of= the various RTP mechanisms. 

 = ;

Cheers

 = ;

-Espen

 [rtp= -topology] - http://www.ietf.org/proceedings/interim/2012/06/07/clue/slides/slides-inter= im-2012-clue-2-6.pdf

 = ;

 = ;

From: Roni Even [mailto:ron.even.tlv@gmail.com]
Sent: 23. august 2012 23:44
To: Espen Berger (espeberg); 'Andy Pepperell'
Cc: clue@ietf.org
Subject: RE: [clue] Notes and action items from 21-aug-2012 design t= eam meeting

 

Hi Espen,<= o:p>

Please loo= k at http://tools.ietf.org/html/draft-westerlund-avtcore-rtp-simulcast-01<= /a>

Roni<= /o:p>

 = ;

From: Espen Berger (espeberg) [mailto:espeberg@cisco.com]
Sent: 23 August, 2012 5:34 PM
To: Roni Even; 'Andy Pepperell'
Cc: clue@ietf.org
Subject: RE: [clue] Notes and action items from 21-aug-2012 design t= eam meeting

 

I think th= e RTP translator topology must be added, where a switching MCU keeps the SS= RC from the originating media provider and rewrites the RTCP.

 = ;

My assumpt= ion is that the MCU does an aggregation based on the various consumer reque= sts and do a configuration towards each provider of media.

 = ;

Cheers

 = ;

-Espen

 = ;

 = ;

From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Roni Even
Sent: 23. august 2012 15:45
To: 'Andy Pepperell'
Cc: clue@ietf.org
Subject: Re: [clue] Notes and action items from 21-aug-2012 design t= eam meeting

 

Hi Andy,

I am looki= ng at the simulcast support and what is not clear to me is in which topolog= ies you see simulcast.

I can unde= rstand a point to point where there is an offer and the receiver selects wh= ich stream it wants. (resolution, frame rate, bit rate and codec (useful for audio), but this is regular offer answer.

The other = topology is RTP mixer where the mixer may receives all simulcast streams fr= om the sender and send each user a stream according to the receiver capability.

 = ;

Are there = other use cases and what topology do you assume?

Roni<= /o:p>

 = ;

 = ;

From: Andy Pepperell [mailto:apeppere@gmail.com]<= /a>
Sent: 22 August, 2012 9:26 AM
To: Roni Even
Cc: Paul Kyzivat; clue@ietf.org=
Subject: Re: [clue] Notes and action items from 21-aug-2012 design t= eam meeting

 

= Hi Roni

On Tue, Aug 21, 2012 at 11:13 P= M, Roni Even <ron.even.tlv@gmail.com> wrote:

Hi Paul,
The current framework does not mention this usage for encoding groups and

 

= I was making a general comment on the readability of the encoding group
support in the framework

 

I think it was me that made the= rash promise to ensure that the framework was clear on this point :)<= /o:p>

 

From what I remember in the mee= ting what we said needing clarification was being able to instantiate a sin= gle capture into multiple encodings - to address this first, the framework = talks about this in section 8, for instance:

Every media capture is assoc= iated with an encoding group, which is used to instantiate that media = capture into one or more encoded streams.

and:

If there are multiple i= ndividual encodings in the group, then a single media capture can be e= ncoded into multiple different streams at the same time...

and from section 9:<= /span>

For each media capture the c= onsumer wants to receive, it configures one or more of the encodings i= n that capture's encoding group<= /span>

 

>[Roni]

>I was making a general comm= ent on the readability of the encoding group support in the framework<= o:p>

 

I'm not sure how to answer this= one, except perhaps asking you to make a more specific comment on the read= ability of the encoding group support in the framework... :)

 

>Is the encoding only f= or defining physical limitation or do we use them also for selecting f= or example a specific encoding in a simulcast for a media=

capture. 

 

To attempt an answer on this on= e, yes, it's true that one usage of the encoding group system was to ensure= that today's Telepresence endpoint devices which are typically formed of 2= , 3, or 4 distinct regular endpoints with some additional control logic were well represented - specifically th= e likely constraint that only, say, the DSP resource on the device connecte= d to the leftmost camera would be able to produce encodings of that camera'= s media capture. However, it would be wrong to say that the encoding group system is "only for defining = physical limitation" as that's only one use, and we didn't want to be = too prescriptive - a single-box software MCU might sensibly separate out it= s main and presentation encodings with separate encoding groups, or use this scheme to capture nuances of switched vs tran= scoded.

 

>General question is if in a= configuration you select a media capture only or also a specific type of c= ontent and how you advertise it (clarify the framework?)<= /p>

 

The configuration (consumer str= eam choice) mechanism is intended to allow the consumer to select both the = set of capture encodings it wishes the provider to send to it, plus charact= eristics of those encodings such as maximum bandwidth / resolution etc. (all of which would be subject to SIP = call level overall restrictions as conveyed by SDP, which would also define= payload types etc. as now).

 

>  (clarify the fr= amework?)

I think it's a fair comment on = the framework that, as compared to the level of detail and number of exampl= e cases relating to provider advertisements and encoding groups then the co= nfiguration / consumer stream choice side of things is perhaps under-represented in the document. This may be s= omething worth addressing - additionally, the messaging / data model docume= nt will by necessity contain full details of all of these aspects.

 

Regards,

 

Andy

 

--_000_E8F5F2C7B2623641BD9ABF0B622D726D0F4D9C7Cxmbrcdx11ciscoc_-- From ron.even.tlv@gmail.com Fri Aug 24 05:04: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 5BA9B21F8707 for ; Fri, 24 Aug 2012 05:04:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2yA5qmtnMlOb for ; Fri, 24 Aug 2012 05:04:38 -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 D9AA421F8495 for ; Fri, 24 Aug 2012 05:04:28 -0700 (PDT) Received: by wicr5 with SMTP id r5so628857wic.13 for ; Fri, 24 Aug 2012 05:04:27 -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:x-mailer:thread-index:content-language; bh=jjVnIUuLDtEgE0rUOmXNShNf7CWZH2EtXArnSA3S/A0=; b=j7nWlZ4PTeGAGtbmt+0e8pbqGPRZPIuB6Ge6m7xNAb1WT+DycUHQHklK+/woBTA1en M5cY5Kb4HP4I7+Gil2nOMtoJQGX95vpIKJzH3MAtKl3etzZjQpt4GnXuz6FaLhYTxU7t ir68t3VChOtcoxURI9qJvifqQ2C891ulcljKjd7d7KDqXnaPPOXLuzX5eVGRamkejcdx RuIi4ICEOzPCvGMey0QzQJBT2p+RW65oYc0rly40ChioDxsGig2mO7oIMmaiKaDjQKrY KJgCCJEQXFe3eNNxcWbBobiGRz2qag5oXymMY+brYnFnXIfwHe7Elg4JQgU5k41/m8Xa Z7sw== Received: by 10.180.82.164 with SMTP id j4mr5031033wiy.18.1345809867795; Fri, 24 Aug 2012 05:04:27 -0700 (PDT) Received: from RoniE (bzq-79-179-223-139.red.bezeqint.net. [79.179.223.139]) by mx.google.com with ESMTPS id r9sm6163148wia.2.2012.08.24.05.04.24 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 24 Aug 2012 05:04:26 -0700 (PDT) From: "Roni Even" To: "'Espen Berger \(espeberg\)'" , "'Andy Pepperell'" References: <004a01cd7fb8$51919da0$f4b4d8e0$@gmail.com> <5033CFA2.50000@alum.mit.edu> <006901cd7fea$3e8b8c20$bba2a460$@gmail.com> <002601cd8135$89425d10$9bc71730$@gmail.com> <006201cd8178$69e36020$3daa2060$@gmail.com> In-Reply-To: Date: Fri, 24 Aug 2012 15:03:06 +0200 Message-ID: <009201cd81f8$cfe498f0$6fadcad0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0093_01CD8209.936FB2E0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIm8qRg8ZZqP+83BAq7zn6qL3zShgJIWkJ2AZIxFQ8BcAqxfwJMUXlzAo4v9rYCtSbjlQLPurtTlji5R8A= Content-Language: en-us Cc: clue@ietf.org Subject: Re: [clue] Notes and action items from 21-aug-2012 design team 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: Fri, 24 Aug 2012 12:04:42 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0093_01CD8209.936FB2E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Espen, This is still a mixer, it terminates RTCP even though it is one SSRC space. At the Interim meeting this topology was not part of the supported topologies for CLUE based on the issue mentioned with it and because it is not supported by RTP. We agreed on media switching mixer and source projection mixer. My understanding is that the in CLUE the MCU will create and offer with the relevant streams also for simulcast. I am also not sure why the consumer need to define the mapping since the advertisement knows what it offers. I think that we will continue the discussion until we see the call flow SDP, RTCP feedback and CLUE since we probably see different models. I will try to work on my view of the call flow. Roni From: Espen Berger (espeberg) [mailto:espeberg@cisco.com] Sent: 24 August, 2012 10:15 AM To: Roni Even; 'Andy Pepperell' Cc: clue@ietf.org Subject: RE: [clue] Notes and action items from 21-aug-2012 design team meeting Hi Roni The reference to RTP translator topology was incorrect, I was thinking about the 'Selective Forwarding Switch' topology that Magnus presented during the June interim meeting. The presentation has addition topologies that are not yet in the RFC5115 RTP topology document, so hopefully someone will update it. Regarding you comment on RTCP RR; A selective forwarding switch can keep track of streams sent and received for each RTP session and rewrite all RTCP SR/RR to make sure that RTCP information is correct for each RTP session. The topology will result in source disappearing and reappearing again based on the MCU policies, which must be understood and handled in terms of the various RTP mechanisms. Cheers -Espen [rtp-topology] - http://www.ietf.org/proceedings/interim/2012/06/07/clue/slides/slides-interi m-2012-clue-2-6.pdf From: Roni Even [mailto:ron.even.tlv@gmail.com] Sent: 23. august 2012 23:44 To: Espen Berger (espeberg); 'Andy Pepperell' Cc: clue@ietf.org Subject: RE: [clue] Notes and action items from 21-aug-2012 design team meeting Hi Espen, Please look at http://tools.ietf.org/html/draft-westerlund-avtcore-rtp-simulcast-01 Roni From: Espen Berger (espeberg) [mailto:espeberg@cisco.com] Sent: 23 August, 2012 5:34 PM To: Roni Even; 'Andy Pepperell' Cc: clue@ietf.org Subject: RE: [clue] Notes and action items from 21-aug-2012 design team meeting I think the RTP translator topology must be added, where a switching MCU keeps the SSRC from the originating media provider and rewrites the RTCP. My assumption is that the MCU does an aggregation based on the various consumer requests and do a configuration towards each provider of media. Cheers -Espen From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Roni Even Sent: 23. august 2012 15:45 To: 'Andy Pepperell' Cc: clue@ietf.org Subject: Re: [clue] Notes and action items from 21-aug-2012 design team meeting Hi Andy, I am looking at the simulcast support and what is not clear to me is in which topologies you see simulcast. I can understand a point to point where there is an offer and the receiver selects which stream it wants. (resolution, frame rate, bit rate and codec (useful for audio), but this is regular offer answer. The other topology is RTP mixer where the mixer may receives all simulcast streams from the sender and send each user a stream according to the receiver capability. Are there other use cases and what topology do you assume? Roni From: Andy Pepperell [mailto:apeppere@gmail.com] Sent: 22 August, 2012 9:26 AM To: Roni Even Cc: Paul Kyzivat; clue@ietf.org Subject: Re: [clue] Notes and action items from 21-aug-2012 design team meeting Hi Roni On Tue, Aug 21, 2012 at 11:13 PM, Roni Even wrote: Hi Paul, The current framework does not mention this usage for encoding groups and I was making a general comment on the readability of the encoding group support in the framework I think it was me that made the rash promise to ensure that the framework was clear on this point :) >From what I remember in the meeting what we said needing clarification was being able to instantiate a single capture into multiple encodings - to address this first, the framework talks about this in section 8, for instance: Every media capture is associated with an encoding group, which is used to instantiate that media capture into one or more encoded streams. and: If there are multiple individual encodings in the group, then a single media capture can be encoded into multiple different streams at the same time... and from section 9: For each media capture the consumer wants to receive, it configures one or more of the encodings in that capture's encoding group >[Roni] >I was making a general comment on the readability of the encoding group support in the framework I'm not sure how to answer this one, except perhaps asking you to make a more specific comment on the readability of the encoding group support in the framework... :) >Is the encoding only for defining physical limitation or do we use them also for selecting for example a specific encoding in a simulcast for a media capture. To attempt an answer on this one, yes, it's true that one usage of the encoding group system was to ensure that today's Telepresence endpoint devices which are typically formed of 2, 3, or 4 distinct regular endpoints with some additional control logic were well represented - specifically the likely constraint that only, say, the DSP resource on the device connected to the leftmost camera would be able to produce encodings of that camera's media capture. However, it would be wrong to say that the encoding group system is "only for defining physical limitation" as that's only one use, and we didn't want to be too prescriptive - a single-box software MCU might sensibly separate out its main and presentation encodings with separate encoding groups, or use this scheme to capture nuances of switched vs transcoded. >General question is if in a configuration you select a media capture only or also a specific type of content and how you advertise it (clarify the framework?) The configuration (consumer stream choice) mechanism is intended to allow the consumer to select both the set of capture encodings it wishes the provider to send to it, plus characteristics of those encodings such as maximum bandwidth / resolution etc. (all of which would be subject to SIP call level overall restrictions as conveyed by SDP, which would also define payload types etc. as now). > (clarify the framework?) I think it's a fair comment on the framework that, as compared to the level of detail and number of example cases relating to provider advertisements and encoding groups then the configuration / consumer stream choice side of things is perhaps under-represented in the document. This may be something worth addressing - additionally, the messaging / data model document will by necessity contain full details of all of these aspects. Regards, Andy ------=_NextPart_000_0093_01CD8209.936FB2E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Espen,

This is still a mixer, it terminates RTCP even though it is one SSRC = space. At the Interim meeting this topology was not part of the = supported topologies for CLUE based on the issue mentioned with it and = because it is not supported by RTP. We agreed on media switching mixer = and source projection mixer.

My understanding is that the in CLUE the MCU will create and offer = with the relevant streams also for simulcast.

 

I am also not sure why the consumer need to define the mapping since = the advertisement knows what it offers.

I think that we will continue the discussion until we see the call = flow SDP, RTCP feedback and CLUE since we probably see different = models.

I will try to work on my view of the call = flow.

Roni

 

From:= = Espen Berger (espeberg) [mailto:espeberg@cisco.com]
Sent: 24 = August, 2012 10:15 AM
To: Roni Even; 'Andy = Pepperell'
Cc: clue@ietf.org
Subject: RE: [clue] = Notes and action items from 21-aug-2012 design team = meeting

 

Hi Roni

 

The reference to RTP translator topology was incorrect, I was = thinking about the ‘Selective Forwarding Switch’ topology = that Magnus presented during the June interim meeting. The presentation = has addition topologies that are not yet in the RFC5115 RTP topology = document, so hopefully someone will update it.

 

Regarding you comment on RTCP RR; A selective forwarding switch can = keep track of streams sent and received for each RTP session and rewrite = all RTCP SR/RR to make sure that RTCP information is correct for each = RTP session. The topology will result in source disappearing and = reappearing again based on the MCU policies, which must be understood = and handled in terms of the various RTP mechanisms.  =

 

Cheers

 

-Espen

 [rtp-topology] - http://www.ietf.org/proceedings/interim/2= 012/06/07/clue/slides/slides-interim-2012-clue-2-6.pdf

 

 

From:= = Roni Even [mailto:ron.even.tlv@gmai= l.com]
Sent: 23. august 2012 23:44
To: Espen = Berger (espeberg); 'Andy Pepperell'
Cc: clue@ietf.org
Subject: RE: = [clue] Notes and action items from 21-aug-2012 design team = meeting

 

Hi Espen,

Please look at http://tools.ietf.org/html/draft-westerlund-avtcore-rtp-simulcast-01=

Roni

 

From:= = Espen Berger (espeberg) [mailto:espeberg@cisco.com]
Sent: 23 August, 2012 5:34 PM
To: Roni Even; = 'Andy Pepperell'
Cc: clue@ietf.org
Subject: RE: = [clue] Notes and action items from 21-aug-2012 design team = meeting

 

I think the RTP translator topology must be added, where a switching = MCU keeps the SSRC from the originating media provider and rewrites the = RTCP.

 

My assumption is that the MCU does an aggregation based on the = various consumer requests and do a configuration towards each provider = of media.

 

Cheers

 

-Espen

 

 

From:= = clue-bounces@ietf.org [mailto:clue-bounces@ietf.= org] On Behalf Of Roni Even
Sent: 23. august 2012 = 15:45
To: 'Andy Pepperell'
Cc: clue@ietf.org
Subject: Re: = [clue] Notes and action items from 21-aug-2012 design team = meeting

 

Hi Andy,

I am looking at the simulcast support and what is not clear to me is = in which topologies you see simulcast.

I can understand a point to point where there is an offer and the = receiver selects which stream it wants. (resolution, frame rate, bit = rate and codec (useful for audio), but this is regular offer = answer.

The other topology is RTP mixer where the mixer may receives all = simulcast streams from the sender and send each user a stream according = to the receiver capability.

 

Are there other use cases and what topology do you = assume?

Roni

 

 

From:= = Andy Pepperell [mailto:apeppere@gmail.com]
Sent: 22 August, 2012 9:26 AM
To: Roni = Even
Cc: Paul Kyzivat; clue@ietf.org
Subject: Re: = [clue] Notes and action items from 21-aug-2012 design team = meeting

 

Hi Roni

On Tue, Aug 21, 2012 at 11:13 PM, Roni Even <ron.even.tlv@gmail.com> wrote:

Hi Paul,
The current framework does not mention = this usage for encoding groups and

 

I was making a = general comment on the readability of the encoding group
support in = the framework

 

I = think it was me that made the rash promise to ensure that the framework = was clear on this point :)

 

From what I remember in the meeting what we said = needing clarification was being able to instantiate a single capture = into multiple encodings - to address this first, the framework talks = about this in section 8, for instance:

Every media capture is associated with an encoding = group, which is used to instantiate that media capture into one or = more encoded streams.

and:

If there are multiple individual encodings in = the group, then a single media capture can be encoded into multiple = different streams at the same = time...

and from = section 9:

For = each media capture the consumer wants to receive, it configures one = or more of the encodings in that capture's encoding = group

 

>[Roni]

>I was making a general comment on the readability = of the encoding group support in the = framework

 

I'm not sure how to answer this one, except perhaps = asking you to make a more specific comment on the readability of the = encoding group support in the framework... = :)

 

>Is the encoding only for defining physical = limitation or do we use them also for selecting for example a = specific encoding in a simulcast for a = media

capture. 

 

To attempt an answer on this one, yes, it's true that = one usage of the encoding group system was to ensure that today's = Telepresence endpoint devices which are typically formed of 2, 3, or 4 = distinct regular endpoints with some additional control logic were well = represented - specifically the likely constraint that only, say, the DSP = resource on the device connected to the leftmost camera would be able to = produce encodings of that camera's media capture. However, it would be = wrong to say that the encoding group system is "only for defining = physical limitation" as that's only one use, and we didn't want to = be too prescriptive - a single-box software MCU might sensibly separate = out its main and presentation encodings with separate encoding groups, = or use this scheme to capture nuances of switched vs = transcoded.

 

>General question is if in a configuration you = select a media capture only or also a specific type of content and how = you advertise it (clarify the framework?)

 

The configuration (consumer stream choice) mechanism = is intended to allow the consumer to select both the set of capture = encodings it wishes the provider to send to it, plus characteristics of = those encodings such as maximum bandwidth / resolution etc. (all of = which would be subject to SIP call level overall restrictions as = conveyed by SDP, which would also define payload types etc. as = now).

 

>  (clarify the = framework?)

I think it's a = fair comment on the framework that, as compared to the level of detail = and number of example cases relating to provider advertisements and = encoding groups then the configuration / consumer stream choice side of = things is perhaps under-represented in the document. This may be = something worth addressing - additionally, the messaging / data model = document will by necessity contain full details of all of these = aspects.

 

Regards,

 

Andy

 

------=_NextPart_000_0093_01CD8209.936FB2E0-- From espeberg@cisco.com Fri Aug 24 07:17: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 5035C21F86EA for ; Fri, 24 Aug 2012 07:17:37 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dkocJe+yD2U9 for ; Fri, 24 Aug 2012 07:17:32 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 2D43321F86E0 for ; Fri, 24 Aug 2012 07:17:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=espeberg@cisco.com; l=34087; q=dns/txt; s=iport; t=1345817848; x=1347027448; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=ubFgBbce+JE0C5mLLOZlCqluHWWIB5myj675FSICsRk=; b=XzBw8lal4W1AKa21UYD80T41FAT6+r6jUgfmgxNk8gdiMY6F4iaC2wff 9MHmn8VcTaPvHi0yGUzNE8l8Bf+uhdY5/6Nb3Jo1p6etfdTsXM1eM7soo YfM8NX7D5H9b4Dfqbrn61lDrN6/sPQwGVl19vJIMEteJlsnfGtHUV95nB U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AscFALCLN1CtJXG8/2dsb2JhbABFgkqvOgGIXYEHgiABAQECAhIBGkwQAgEIDgMEAQELFgEGByERFAkIAgQBDQUIARmHXAMMC5kHlkENiU6KJWOGMWADlAKCZ4l5gyCBZ4Jj X-IronPort-AV: E=Sophos;i="4.80,304,1344211200"; d="scan'208,217";a="114977912" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-6.cisco.com with ESMTP; 24 Aug 2012 14:17:26 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id q7OEHQgj020113 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 24 Aug 2012 14:17:26 GMT Received: from xmb-rcd-x11.cisco.com ([169.254.1.118]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.02.0298.004; Fri, 24 Aug 2012 09:17:26 -0500 From: "Espen Berger (espeberg)" To: Roni Even , "'Andy Pepperell'" Thread-Topic: [clue] Notes and action items from 21-aug-2012 design team meeting Thread-Index: AQHNf+IRHY0up2/Nn0inZTQ0ksejcpdlwsmAgAH8UYD//8NfUIAAwmKAgABYDPCAAKjBAP//vxbA Date: Fri, 24 Aug 2012 14:17:25 +0000 Message-ID: References: <004a01cd7fb8$51919da0$f4b4d8e0$@gmail.com> <5033CFA2.50000@alum.mit.edu> <006901cd7fea$3e8b8c20$bba2a460$@gmail.com> <002601cd8135$89425d10$9bc71730$@gmail.com> <006201cd8178$69e36020$3daa2060$@gmail.com> <009201cd81f8$cfe498f0$6fadcad0$@gmail.com> In-Reply-To: <009201cd81f8$cfe498f0$6fadcad0$@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.147.112.147] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19134.005 x-tm-as-result: No--55.472000-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_E8F5F2C7B2623641BD9ABF0B622D726D0F4D9EF0xmbrcdx11ciscoc_" MIME-Version: 1.0 Cc: "clue@ietf.org" Subject: Re: [clue] Notes and action items from 21-aug-2012 design team 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: Fri, 24 Aug 2012 14:17:37 -0000 --_000_E8F5F2C7B2623641BD9ABF0B622D726D0F4D9EF0xmbrcdx11ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable As long as we support at least one topology that allow for keeping the SSRC= through the MCU. -Espen From: Roni Even [mailto:ron.even.tlv@gmail.com] Sent: 24. august 2012 15:03 To: Espen Berger (espeberg); 'Andy Pepperell' Cc: clue@ietf.org Subject: RE: [clue] Notes and action items from 21-aug-2012 design team mee= ting Espen, This is still a mixer, it terminates RTCP even though it is one SSRC space.= At the Interim meeting this topology was not part of the supported topolog= ies for CLUE based on the issue mentioned with it and because it is not sup= ported by RTP. We agreed on media switching mixer and source projection mix= er. My understanding is that the in CLUE the MCU will create and offer with the= relevant streams also for simulcast. I am also not sure why the consumer need to define the mapping since the ad= vertisement knows what it offers. I think that we will continue the discussion until we see the call flow SDP= , RTCP feedback and CLUE since we probably see different models. I will try to work on my view of the call flow. Roni From: Espen Berger (espeberg) [mailto:espeberg@cisco.com] Sent: 24 August, 2012 10:15 AM To: Roni Even; 'Andy Pepperell' Cc: clue@ietf.org Subject: RE: [clue] Notes and action items from 21-aug-2012 design team mee= ting Hi Roni The reference to RTP translator topology was incorrect, I was thinking abou= t the 'Selective Forwarding Switch' topology that Magnus presented during t= he June interim meeting. The presentation has addition topologies that are = not yet in the RFC5115 RTP topology document, so hopefully someone will upd= ate it. Regarding you comment on RTCP RR; A selective forwarding switch can keep tr= ack of streams sent and received for each RTP session and rewrite all RTCP = SR/RR to make sure that RTCP information is correct for each RTP session. T= he topology will result in source disappearing and reappearing again based = on the MCU policies, which must be understood and handled in terms of the v= arious RTP mechanisms. Cheers -Espen [rtp-topology] - http://www.ietf.org/proceedings/interim/2012/06/07/clue/s= lides/slides-interim-2012-clue-2-6.pdf From: Roni Even [mailto:ron.even.tlv@gmail.com] Sent: 23. august 2012 23:44 To: Espen Berger (espeberg); 'Andy Pepperell' Cc: clue@ietf.org Subject: RE: [clue] Notes and action items from 21-aug-2012 design team mee= ting Hi Espen, Please look at http://tools.ietf.org/html/draft-westerlund-avtcore-rtp-simu= lcast-01 Roni From: Espen Berger (espeberg) [mailto:espeberg@cisco.com] Sent: 23 August, 2012 5:34 PM To: Roni Even; 'Andy Pepperell' Cc: clue@ietf.org Subject: RE: [clue] Notes and action items from 21-aug-2012 design team mee= ting I think the RTP translator topology must be added, where a switching MCU ke= eps the SSRC from the originating media provider and rewrites the RTCP. My assumption is that the MCU does an aggregation based on the various cons= umer requests and do a configuration towards each provider of media. Cheers -Espen From: clue-bounces@ietf.org [mailto:clue-boun= ces@ietf.org] On Behalf Of Roni Even Sent: 23. august 2012 15:45 To: 'Andy Pepperell' Cc: clue@ietf.org Subject: Re: [clue] Notes and action items from 21-aug-2012 design team mee= ting Hi Andy, I am looking at the simulcast support and what is not clear to me is in whi= ch topologies you see simulcast. I can understand a point to point where there is an offer and the receiver = selects which stream it wants. (resolution, frame rate, bit rate and codec = (useful for audio), but this is regular offer answer. The other topology is RTP mixer where the mixer may receives all simulcast = streams from the sender and send each user a stream according to the receiv= er capability. Are there other use cases and what topology do you assume? Roni From: Andy Pepperell [mailto:apeppere@gmail.com] Sent: 22 August, 2012 9:26 AM To: Roni Even Cc: Paul Kyzivat; clue@ietf.org Subject: Re: [clue] Notes and action items from 21-aug-2012 design team mee= ting Hi Roni On Tue, Aug 21, 2012 at 11:13 PM, Roni Even > wrote: Hi Paul, The current framework does not mention this usage for encoding groups and I was making a general comment on the readability of the encoding group support in the framework I think it was me that made the rash promise to ensure that the framework w= as clear on this point :) >From what I remember in the meeting what we said needing clarification was = being able to instantiate a single capture into multiple encodings - to add= ress this first, the framework talks about this in section 8, for instance: Every media capture is associated with an encoding group, which is used to = instantiate that media capture into one or more encoded streams. and: If there are multiple individual encodings in the group, then a single medi= a capture can be encoded into multiple different streams at the same time..= . and from section 9: For each media capture the consumer wants to receive, it configures one or = more of the encodings in that capture's encoding group >[Roni] >I was making a general comment on the readability of the encoding group su= pport in the framework I'm not sure how to answer this one, except perhaps asking you to make a mo= re specific comment on the readability of the encoding group support in the= framework... :) >Is the encoding only for defining physical limitation or do we use them al= so for selecting for example a specific encoding in a simulcast for a media capture. To attempt an answer on this one, yes, it's true that one usage of the enco= ding group system was to ensure that today's Telepresence endpoint devices = which are typically formed of 2, 3, or 4 distinct regular endpoints with so= me additional control logic were well represented - specifically the likely= constraint that only, say, the DSP resource on the device connected to the= leftmost camera would be able to produce encodings of that camera's media = capture. However, it would be wrong to say that the encoding group system i= s "only for defining physical limitation" as that's only one use, and we di= dn't want to be too prescriptive - a single-box software MCU might sensibly= separate out its main and presentation encodings with separate encoding gr= oups, or use this scheme to capture nuances of switched vs transcoded. >General question is if in a configuration you select a media capture only = or also a specific type of content and how you advertise it (clarify the fr= amework?) The configuration (consumer stream choice) mechanism is intended to allow t= he consumer to select both the set of capture encodings it wishes the provi= der to send to it, plus characteristics of those encodings such as maximum = bandwidth / resolution etc. (all of which would be subject to SIP call leve= l overall restrictions as conveyed by SDP, which would also define payload = types etc. as now). > (clarify the framework?) I think it's a fair comment on the framework that, as compared to the level= of detail and number of example cases relating to provider advertisements = and encoding groups then the configuration / consumer stream choice side of= things is perhaps under-represented in the document. This may be something= worth addressing - additionally, the messaging / data model document will = by necessity contain full details of all of these aspects. Regards, Andy --_000_E8F5F2C7B2623641BD9ABF0B622D726D0F4D9EF0xmbrcdx11ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

As long as= we support at least one topology that allow for keeping the SSRC through t= he MCU.

 = ;

-Espen

 = ;

 = ;

From: Roni Even [mailto:ron.even.tlv@gmail.com]
Sent: 24. august 2012 15:03
To: Espen Berger (espeberg); 'Andy Pepperell'
Cc: clue@ietf.org
Subject: RE: [clue] Notes and action items from 21-aug-2012 design t= eam meeting

 

Espen,

This is st= ill a mixer, it terminates RTCP even though it is one SSRC space. At the In= terim meeting this topology was not part of the supported topologies for CLUE based on the issue mentioned with it and because it is= not supported by RTP. We agreed on media switching mixer and source projec= tion mixer.

My underst= anding is that the in CLUE the MCU will create and offer with the relevant = streams also for simulcast.

 = ;

I am also = not sure why the consumer need to define the mapping since the advertisemen= t knows what it offers.

I think th= at we will continue the discussion until we see the call flow SDP, RTCP fee= dback and CLUE since we probably see different models.

I will try= to work on my view of the call flow.

Roni<= /o:p>

 = ;

From: Espen Berger (espeberg) [mailto:espeberg@cisco.com]<= /a>
Sent: 24 August, 2012 10:15 AM
To: Roni Even; 'Andy Pepperell'
Cc: clue@ietf.org
Subject: RE: [clue] Notes and action items from 21-aug-2012 design t= eam meeting

 

Hi Roni=

 <= /p>

The refere= nce to RTP translator topology was incorrect, I was thinking about the R= 16;Selective Forwarding Switch’ topology that Magnus presented during the June interim meeting. The presentation has addition topologies that ar= e not yet in the RFC5115 RTP topology document, so hopefully someone will u= pdate it.

 = ;

Regarding = you comment on RTCP RR; A selective forwarding switch can keep track of str= eams sent and received for each RTP session and rewrite all RTCP SR/RR to make sure that RTCP information is correct for each RTP sess= ion. The topology will result in source disappearing and reappearing again = based on the MCU policies, which must be understood and handled in terms of= the various RTP mechanisms. 

 = ;

Cheers

 = ;

-Espen

 [rtp= -topology] - http://www.ietf.org/proceedings/interim/2012/06/07/clue/slides/slides-inter= im-2012-clue-2-6.pdf

 = ;

 = ;

From: Roni Even [mailto:ron.even.tlv@gma= il.com]
Sent: 23. august 2012 23:44
To: Espen Berger (espeberg); 'Andy Pepperell'
Cc: clue@ietf.org
Subject: RE: [clue] Notes and action items from 21-aug-2012 design t= eam meeting

 

Hi Espen,<= o:p>

Please loo= k at http://tools.ietf.org/html/draft-westerlund-avtcore-rtp-simulcast-01<= /a>

Roni<= /o:p>

 = ;

 

I think th= e RTP translator topology must be added, where a switching MCU keeps the SS= RC from the originating media provider and rewrites the RTCP.

 = ;

My assumpt= ion is that the MCU does an aggregation based on the various consumer reque= sts and do a configuration towards each provider of media.

 = ;

Cheers

 = ;

-Espen

 = ;

 = ;

From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Roni Even
Sent: 23. august 2012 15:45
To: 'Andy Pepperell'
Cc: clue@ietf.org
Subject: Re: [clue] Notes and action items from 21-aug-2012 design t= eam meeting

 

Hi Andy,

I am looki= ng at the simulcast support and what is not clear to me is in which topolog= ies you see simulcast.

I can unde= rstand a point to point where there is an offer and the receiver selects wh= ich stream it wants. (resolution, frame rate, bit rate and codec (useful for audio), but this is regular offer answer.

The other = topology is RTP mixer where the mixer may receives all simulcast streams fr= om the sender and send each user a stream according to the receiver capability.

 = ;

Are there = other use cases and what topology do you assume?

Roni<= /o:p>

 = ;

 = ;

From: Andy Pepperell [mailto:apeppere@gmail.com]<= /a>
Sent: 22 August, 2012 9:26 AM
To: Roni Even
Cc: Paul Kyzivat; clue@ietf.org=
Subject: Re: [clue] Notes and action items from 21-aug-2012 design t= eam meeting

 

= Hi Roni

On Tue, Aug 21, 2012 at 11:13 P= M, Roni Even <ron.even.tlv@gmail.com> wrote:

Hi Paul,
The current framework does not mention this usage for encoding groups and

 

= I was making a general comment on the readability of the encoding group
support in the framework

 

I think it was me that made the= rash promise to ensure that the framework was clear on this point :)<= /o:p>

 

From what I remember in the mee= ting what we said needing clarification was being able to instantiate a sin= gle capture into multiple encodings - to address this first, the framework = talks about this in section 8, for instance:

Every media capture is assoc= iated with an encoding group, which is used to instantiate that media = capture into one or more encoded streams.

and:

If there are multiple i= ndividual encodings in the group, then a single media capture can be e= ncoded into multiple different streams at the same time...

and from section 9:<= /span>

For each media capture the c= onsumer wants to receive, it configures one or more of the encodings i= n that capture's encoding group<= /span>

 

>[Roni]

>I was making a general comm= ent on the readability of the encoding group support in the framework<= o:p>

 

I'm not sure how to answer this= one, except perhaps asking you to make a more specific comment on the read= ability of the encoding group support in the framework... :)

 

>Is the encoding only f= or defining physical limitation or do we use them also for selecting f= or example a specific encoding in a simulcast for a media=

capture. 

 

To attempt an answer on this on= e, yes, it's true that one usage of the encoding group system was to ensure= that today's Telepresence endpoint devices which are typically formed of 2= , 3, or 4 distinct regular endpoints with some additional control logic were well represented - specifically th= e likely constraint that only, say, the DSP resource on the device connecte= d to the leftmost camera would be able to produce encodings of that camera'= s media capture. However, it would be wrong to say that the encoding group system is "only for defining = physical limitation" as that's only one use, and we didn't want to be = too prescriptive - a single-box software MCU might sensibly separate out it= s main and presentation encodings with separate encoding groups, or use this scheme to capture nuances of switched vs tran= scoded.

 

>General question is if in a= configuration you select a media capture only or also a specific type of c= ontent and how you advertise it (clarify the framework?)<= /p>

 

The configuration (consumer str= eam choice) mechanism is intended to allow the consumer to select both the = set of capture encodings it wishes the provider to send to it, plus charact= eristics of those encodings such as maximum bandwidth / resolution etc. (all of which would be subject to SIP = call level overall restrictions as conveyed by SDP, which would also define= payload types etc. as now).

 

>  (clarify the fr= amework?)

I think it's a fair comment on = the framework that, as compared to the level of detail and number of exampl= e cases relating to provider advertisements and encoding groups then the co= nfiguration / consumer stream choice side of things is perhaps under-represented in the document. This may be s= omething worth addressing - additionally, the messaging / data model docume= nt will by necessity contain full details of all of these aspects.

 

Regards,

 

Andy

 

--_000_E8F5F2C7B2623641BD9ABF0B622D726D0F4D9EF0xmbrcdx11ciscoc_-- From mary.ietf.barnes@gmail.com Fri Aug 24 07:41: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 C5A9221F86E0 for ; Fri, 24 Aug 2012 07:41:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.521 X-Spam-Level: X-Spam-Status: No, score=-103.521 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ChLvMG5nz6aP for ; Fri, 24 Aug 2012 07:41:24 -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 7360A21F8683 for ; Fri, 24 Aug 2012 07:41:23 -0700 (PDT) Received: by lahm15 with SMTP id m15so1243993lah.31 for ; Fri, 24 Aug 2012 07:41:22 -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=rpu3tlIKCPUIkehbgyVcwqOZC947Yt2aivRqlH9rm9s=; b=UmrsyXl5EaxH3m0Ldcwg8olqtwDbrT06XDj9uYN5fcj1ytlHDgCWmOl0FVF1xJTnWu fUyvossTHIpzqqXCbM1rMWVf5Wh91gMy8Nwwy0O7H9PckV0rsfoQGbqyzSrux1eQpY04 M9OgDAiVClKjpxIf3wWpSUrs7cjQGBOPNoIxjYNOXmqonMbHAC23WFaVDy3nKLhrx8A8 J7t9AVpTmCYPRJFO1foXjBdmTuCdfVTEahcQj5/fJYFLlDC8v/1KPvyYw+JMBPCfv/JI /NMCd2/d56dWXj31a6Fmvv9jxrDrenUdUE0hZ9prfRLyBDAgjsi3oQzwbQqPoKJ/uWtX QMSw== MIME-Version: 1.0 Received: by 10.152.123.206 with SMTP id mc14mr6079209lab.33.1345819282164; Fri, 24 Aug 2012 07:41:22 -0700 (PDT) Received: by 10.112.85.196 with HTTP; Fri, 24 Aug 2012 07:41:22 -0700 (PDT) In-Reply-To: References: <004a01cd7fb8$51919da0$f4b4d8e0$@gmail.com> <5033CFA2.50000@alum.mit.edu> <006901cd7fea$3e8b8c20$bba2a460$@gmail.com> <002601cd8135$89425d10$9bc71730$@gmail.com> <006201cd8178$69e36020$3daa2060$@gmail.com> <009201cd81f8$cfe498f0$6fadcad0$@gmail.com> Date: Fri, 24 Aug 2012 09:41:22 -0500 Message-ID: From: Mary Barnes To: "Espen Berger (espeberg)" Content-Type: multipart/alternative; boundary=f46d044284ec3eca0f04c803f834 Cc: "clue@ietf.org" Subject: Re: [clue] Notes and action items from 21-aug-2012 design team 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: Fri, 24 Aug 2012 14:41:25 -0000 --f46d044284ec3eca0f04c803f834 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Roni included the topologies that we agreed at the interim (from Magnus' presentation) in the rtp-mapping draft: http://datatracker.ietf.org/doc/draft-even-clue-rtp-mapping/?include_text= =3D1 It would be really good if people could review those and suggest changes/additions based upon what's already written down. We really need this well documented (based on WG consensus) for our CLUE deliverables. On that topic, it would be good to take a step back and look at the RTP requirements that are in the rtp-usage draft: http://www.ietf.org/id/draft-lennox-clue-rtp-usage-04.txt (Section 9 in particular). As we also should have that clearly documented and agreed by the WG. Mary. On Fri, Aug 24, 2012 at 9:17 AM, Espen Berger (espeberg) wrote: > As long as we support at least one topology that allow for keeping the > SSRC through the MCU. **** > > ** ** > > -Espen **** > > ** ** > > ** ** > > *From:* Roni Even [mailto:ron.even.tlv@gmail.com] > *Sent:* 24. august 2012 15:03 > > *To:* Espen Berger (espeberg); 'Andy Pepperell' > *Cc:* clue@ietf.org > *Subject:* RE: [clue] Notes and action items from 21-aug-2012 design team > meeting**** > > ** ** > > Espen,**** > > This is still a mixer, it terminates RTCP even though it is one SSRC > space. At the Interim meeting this topology was not part of the supported > topologies for CLUE based on the issue mentioned with it and because it i= s > not supported by RTP. We agreed on media switching mixer and source > projection mixer.**** > > My understanding is that the in CLUE the MCU will create and offer with > the relevant streams also for simulcast.**** > > ** ** > > I am also not sure why the consumer need to define the mapping since the > advertisement knows what it offers.**** > > I think that we will continue the discussion until we see the call flow > SDP, RTCP feedback and CLUE since we probably see different models.**** > > I will try to work on my view of the call flow.**** > > Roni**** > > ** ** > > *From:* Espen Berger (espeberg) [mailto:espeberg@cisco.com] > *Sent:* 24 August, 2012 10:15 AM > *To:* Roni Even; 'Andy Pepperell' > *Cc:* clue@ietf.org > *Subject:* RE: [clue] Notes and action items from 21-aug-2012 design team > meeting**** > > ** ** > > Hi Roni**** > > ** ** > > The reference to RTP translator topology was incorrect, I was thinking > about the =91Selective Forwarding Switch=92 topology that Magnus presente= d > during the June interim meeting. The presentation has addition topologies > that are not yet in the RFC5115 RTP topology document, so hopefully someo= ne > will update it. **** > > ** ** > > Regarding you comment on RTCP RR; A selective forwarding switch can keep > track of streams sent and received for each RTP session and rewrite all > RTCP SR/RR to make sure that RTCP information is correct for each RTP > session. The topology will result in source disappearing and reappearing > again based on the MCU policies, which must be understood and handled in > terms of the various RTP mechanisms. **** > > ** ** > > Cheers **** > > ** ** > > -Espen **** > > [rtp-topology] - > http://www.ietf.org/proceedings/interim/2012/06/07/clue/slides/slides-int= erim-2012-clue-2-6.pdf > **** > > ** ** > > ** ** > > *From:* Roni Even [mailto:ron.even.tlv@gmail.com] > *Sent:* 23. august 2012 23:44 > *To:* Espen Berger (espeberg); 'Andy Pepperell' > *Cc:* clue@ietf.org > *Subject:* RE: [clue] Notes and action items from 21-aug-2012 design team > meeting**** > > ** ** > > Hi Espen,**** > > Please look at > http://tools.ietf.org/html/draft-westerlund-avtcore-rtp-simulcast-01**** > > Roni**** > > ** ** > > *From:* Espen Berger (espeberg) [mailto:espeberg@cisco.com] > *Sent:* 23 August, 2012 5:34 PM > *To:* Roni Even; 'Andy Pepperell' > *Cc:* clue@ietf.org > *Subject:* RE: [clue] Notes and action items from 21-aug-2012 design team > meeting**** > > ** ** > > I think the RTP translator topology must be added, where a switching MCU > keeps the SSRC from the originating media provider and rewrites the RTCP. > **** > > ** ** > > My assumption is that the MCU does an aggregation based on the various > consumer requests and do a configuration towards each provider of media. = * > *** > > ** ** > > Cheers **** > > ** ** > > -Espen **** > > ** ** > > ** ** > > *From:* clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On Behalf > Of *Roni Even > *Sent:* 23. august 2012 15:45 > *To:* 'Andy Pepperell' > *Cc:* clue@ietf.org > *Subject:* Re: [clue] Notes and action items from 21-aug-2012 design team > meeting**** > > ** ** > > Hi Andy,**** > > I am looking at the simulcast support and what is not clear to me is in > which topologies you see simulcast.**** > > I can understand a point to point where there is an offer and the receive= r > selects which stream it wants. (resolution, frame rate, bit rate and code= c > (useful for audio), but this is regular offer answer.**** > > The other topology is RTP mixer where the mixer may receives all simulcas= t > streams from the sender and send each user a stream according to the > receiver capability. **** > > ** ** > > Are there other use cases and what topology do you assume?**** > > Roni**** > > ** ** > > ** ** > > *From:* Andy Pepperell [mailto:apeppere@gmail.com] > *Sent:* 22 August, 2012 9:26 AM > *To:* Roni Even > *Cc:* Paul Kyzivat; clue@ietf.org > *Subject:* Re: [clue] Notes and action items from 21-aug-2012 design team > meeting**** > > ** ** > > Hi Roni**** > > On Tue, Aug 21, 2012 at 11:13 PM, Roni Even > wrote:**** > > Hi Paul, > The current framework does not mention this usage for encoding groups and= * > *** > > **** > > I was making a general comment on the readability of the encoding group > support in the framework**** > > **** > > I think it was me that made the rash promise to ensure that the framework > was clear on this point :)**** > > ** ** > > From what I remember in the meeting what we said needing clarification wa= s > being able to instantiate a single capture into multiple encodings - to > address this first, the framework talks about this in section 8, for > instance:**** > > *Every media capture is associated with an encoding group, which is used > to instantiate that media capture into one or more encoded streams.***** > > and:**** > > *If there are multiple individual encodings in the group, then a single > media capture can be encoded into multiple different streams at the same > time...***** > > and from section 9:**** > > *For each media capture the consumer wants to receive, it configures one > or more of the encodings in that capture's encoding group***** > > ** ** > > >[Roni]**** > > >I was making a general comment on the readability of the encoding > group support in the framework**** > > ** ** > > I'm not sure how to answer this one, except perhaps asking you to make a > more specific comment on the readability of the encoding group support in > the framework... :)**** > > ** ** > > >Is the encoding only for defining physical limitation or do we use them > also for selecting for example a specific encoding in a simulcast for a > media**** > > capture. **** > > ** ** > > To attempt an answer on this one, yes, it's true that one usage of the > encoding group system was to ensure that today's Telepresence endpoint > devices which are typically formed of 2, 3, or 4 distinct regular endpoin= ts > with some additional control logic were well represented - specifically t= he > likely constraint that only, say, the DSP resource on the device connecte= d > to the leftmost camera would be able to produce encodings of that camera'= s > media capture. However, it would be wrong to say that the encoding group > system is "only for defining physical limitation" as that's only one use, > and we didn't want to be too prescriptive - a single-box software MCU mig= ht > sensibly separate out its main and presentation encodings with separate > encoding groups, or use this scheme to capture nuances of switched vs > transcoded.**** > > ** ** > > >General question is if in a configuration you select a media capture onl= y > or also a specific type of content and how you advertise it (clarify the > framework?)**** > > ** ** > > The configuration (consumer stream choice) mechanism is intended to allow > the consumer to select both the set of capture encodings it wishes the > provider to send to it, plus characteristics of those encodings such as > maximum bandwidth / resolution etc. (all of which would be subject to SIP > call level overall restrictions as conveyed by SDP, which would also defi= ne > payload types etc. as now).**** > > ** ** > > > (clarify the framework?)**** > > I think it's a fair comment on the framework that, as compared to the > level of detail and number of example cases relating to provider > advertisements and encoding groups then the configuration / consumer stre= am > choice side of things is perhaps under-represented in the document. This > may be something worth addressing - additionally, the messaging / data > model document will by necessity contain full details of all of these > aspects.**** > > ** ** > > Regards,**** > > ** ** > > Andy**** > > ** ** > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > --f46d044284ec3eca0f04c803f834 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Roni included the topologies that we agreed at the interim (from Magnus'= ; presentation) in the rtp-mapping draft:
http://dat= atracker.ietf.org/doc/draft-even-clue-rtp-mapping/?include_text=3D1

It would be really good if people could review those an= d suggest changes/additions based upon what's already written down. =A0= We really need this well documented (based on WG consensus) for our CLUE de= liverables.

On that topic, it would be good to take a step back and= look at the RTP requirements that are in the rtp-usage draft:=A0
http= ://www.ietf.org/id/draft-lennox-clue-rtp-usage-04.txt (Section 9 in par= ticular).
As we also should have that clearly documented and agreed by the WG. = =A0

Mary.=A0

On Fri, Aug 24, 2012 at 9:17 AM, Espen Berger (espeberg) <espeberg@cisc= o.com> wrote:

As long as= we support at least one topology that allow for keeping the SSRC through t= he MCU.

=A0=

-Espen

=A0=

=A0=

From: Roni Even [mailto:ron.even.tlv@gmail.com]
Sent: 24. august 2012 15:03


To: Espen Berger (espeberg); 'Andy Pepperell'
Cc: clue@ietf.org=
Subject: RE: [clue] Notes and action items from 21-aug-2012 design t= eam meeting

=A0

Espen,<= /u>

This is st= ill a mixer, it terminates RTCP even though it is one SSRC space. At the In= terim meeting this topology was not part of the supported topologies for CLUE based on the issue mentioned with it and because it is= not supported by RTP. We agreed on media switching mixer and source projec= tion mixer.

My underst= anding is that the in CLUE the MCU will create and offer with the relevant = streams also for simulcast.

=A0=

I am also = not sure why the consumer need to define the mapping since the advertisemen= t knows what it offers.

I think th= at we will continue the discussion until we see the call flow SDP, RTCP fee= dback and CLUE since we probably see different models.=

I will try= to work on my view of the call flow.

Roni

=A0=

From: Espen Berger (espeberg) [mailto:es= peberg@cisco.com]
Sent: 24 August, 2012 10:15 AM
To: Roni Even; 'Andy Pepperell'
Cc: clue@ietf.org=
Subject: RE: [clue] Notes and action items from 21-aug-2012 design t= eam meeting

=A0

Hi Roni

=A0<= /p>

The refere= nce to RTP translator topology was incorrect, I was thinking about the =91S= elective Forwarding Switch=92 topology that Magnus presented during the June interim meeting. The presentation has addition topologies that ar= e not yet in the RFC5115 RTP topology document, so hopefully someone will u= pdate it.

=A0=

Regarding = you comment on RTCP RR; A selective forwarding switch can keep track of str= eams sent and received for each RTP session and rewrite all RTCP SR/RR to make sure that RTCP information is correct for each RTP sess= ion. The topology will result in source disappearing and reappearing again = based on the MCU policies, which must be understood and handled in terms of= the various RTP mechanisms.=A0

=A0=

Cheers

=A0=

-Espen

=A0[rtp-to= pology] - http://www.ietf.org/proceedings/interim/2012/06/07/clue/slides/slides-inter= im-2012-clue-2-6.pdf

=A0=

=A0=

From: Roni Even [mailt= o:ron.even.tlv@gmail.com]
Sent: 23. august 2012 23:44
To: Espen Berger (espeberg); 'Andy Pepperell'
Cc: clue@ietf.org=
Subject: RE: [clue] Notes and action items from 21-aug-2012 design t= eam meeting

=A0

Hi Espen,<= u>

Please loo= k at http://tools.ietf.org/html/draft-westerlund-avtcore= -rtp-simulcast-01

Roni

=A0=

From: Espen Berger (espeberg) [mailto:es= peberg@cisco.com]
Sent: 23 August, 2012 5:34 PM
To: Roni Even; 'Andy Pepperell'
Cc: clue@ietf.org=
Subject: RE: [clue] Notes and action items from 21-aug-2012 design t= eam meeting

=A0

I think th= e RTP translator topology must be added, where a switching MCU keeps the SS= RC from the originating media provider and rewrites the RTCP.

=A0=

My assumpt= ion is that the MCU does an aggregation based on the various consumer reque= sts and do a configuration towards each provider of media.

=A0=

Cheers

=A0=

-Espen

=A0=

=A0=

From: clue-bounces@iet= f.org [mailto:clue-bounces@ietf.org] On Behalf Of Roni Even
Sent: 23. august 2012 15:45
To: 'Andy Pepperell'
Cc: clue@ietf.org=
Subject: Re: [clue] Notes and action items from 21-aug-2012 design t= eam meeting

=A0

Hi Andy,

I am looki= ng at the simulcast support and what is not clear to me is in which topolog= ies you see simulcast.

I can unde= rstand a point to point where there is an offer and the receiver selects wh= ich stream it wants. (resolution, frame rate, bit rate and codec (useful for audio), but this is regular offer answer.<= /span>

The other = topology is RTP mixer where the mixer may receives all simulcast streams fr= om the sender and send each user a stream according to the receiver capability.

=A0=

Are there = other use cases and what topology do you assume?

Roni

=A0=

=A0=

From: Andy Pepperell [mailto:ap= eppere@gmail.com]
Sent: 22 August, 2012 9:26 AM
To: Roni Even
Cc: Paul Kyzivat; clue@ietf.org
Subject: Re: [clue] Notes and action items from 21-aug-2012 design t= eam meeting

=A0

= Hi Roni

On Tue, Aug 21, 2012 at 11:13 P= M, Roni Even <ron.even.tlv@gmail.com> wrote:

Hi Paul,
The current framework does not mention this usage for encoding groups and

=A0

= I was making a general comment on the readability of the encoding group
support in the framework

=A0

I think it was me that made the= rash promise to ensure that the framework was clear on this point :)

=A0

From what I remember in the mee= ting what we said needing clarification was being able to instantiate a sin= gle capture into multiple encodings - to address this first, the framework = talks about this in section 8, for instance:

Every media capture is assoc= iated with an encoding group, which is=A0used to instantiate that media cap= ture into one or more encoded=A0streams.=

and:

If there are multiple=A0indi= vidual encodings in the group, then a single media capture can be=A0encoded= into multiple different streams at the same time...

and from section 9:

For each media capture the c= onsumer wants to receive, it configures=A0one or more of the encodings in t= hat capture's encoding group<= /u>

=A0

>[Roni]=

>I was making a general comm= ent on the readability of the encoding group=A0support in the framework<= /u>

=A0

I'm not sure how to answer = this one, except perhaps asking you to make a more specific comment on the = readability of the encoding group support in the framework... :)<= /u>

=A0

>Is the=A0encoding only for = defining physical limitation or do we use them also=A0for selecting for exa= mple a specific encoding in a simulcast for a media

capture.=A0

=A0

To attempt an answer on this on= e, yes, it's true that one usage of the encoding group system was to en= sure that today's Telepresence endpoint devices which are typically for= med of 2, 3, or 4 distinct regular endpoints with some additional control logic were well represented - specifically th= e likely constraint that only, say, the DSP resource on the device connecte= d to the leftmost camera would be able to produce encodings of that camera&= #39;s media capture. However, it would be wrong to say that the encoding group system is "only for defining = physical limitation" as that's only one use, and we didn't wan= t to be too prescriptive - a single-box software MCU might sensibly separat= e out its main and presentation encodings with separate encoding groups, or use this scheme to capture nuances of switched vs tran= scoded.

=A0

>General question is if in a= configuration you select a media capture only or also a specific type of c= ontent and how you advertise it (clarify the framework?)

=A0

The configuration (consumer str= eam choice) mechanism is intended to allow the consumer to select both the = set of capture encodings it wishes the provider to send to it, plus charact= eristics of those encodings such as maximum bandwidth / resolution etc. (all of which would be subject to SIP = call level overall restrictions as conveyed by SDP, which would also define= payload types etc. as now).

=A0

>=A0=A0(clarify the framewor= k?)

I think it's a fair comment= on the framework that, as compared to the level of detail and number of ex= ample cases relating to provider advertisements and encoding groups then th= e configuration / consumer stream choice side of things is perhaps under-represented in the document. This may be s= omething worth addressing - additionally, the messaging / data model docume= nt will by necessity contain full details of all of these aspects.

=A0

Regards,

=A0

Andy

=A0


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


--f46d044284ec3eca0f04c803f834-- From internet-drafts@ietf.org Sat Aug 25 23:40: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 5651121F84F1; Sat, 25 Aug 2012 23:40:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.557 X-Spam-Level: X-Spam-Status: No, score=-102.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nDDdFkQIKQ7k; Sat, 25 Aug 2012 23:40:09 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D548121F846D; Sat, 25 Aug 2012 23:40:09 -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.34 Message-ID: <20120826064009.1615.88387.idtracker@ietfa.amsl.com> Date: Sat, 25 Aug 2012 23:40:09 -0700 Cc: clue@ietf.org Subject: [clue] I-D Action: draft-ietf-clue-telepresence-use-cases-04.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: Sun, 26 Aug 2012 06:40:10 -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 tElepres= ence Working Group of the IETF. Title : Use Cases for Telepresence Multi-streams Author(s) : Allyn Romanow Stephen Botzko Mark Duckworth Roni Even Iformata Communications Filename : draft-ietf-clue-telepresence-use-cases-04.txt Pages : 17 Date : 2012-08-25 Abstract: Telepresence conferencing systems seek to create the sense of really being present for the participants. A number of techniques for handling audio and video streams are used to create this experience. When these techniques are not similar, interoperability between different systems is difficult at best, and often not possible. Conveying information about the relationships between multiple streams of media would allow senders and receivers to make choices to allow telepresence systems to interwork. This memo describes the most typical and important use cases for sending multiple streams in a telepresence conference. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-clue-telepresence-use-cases There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-clue-telepresence-use-cases-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-clue-telepresence-use-cases-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From roni.even@mail01.huawei.com Sat Aug 25 23:43:18 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 C515021F846D for ; Sat, 25 Aug 2012 23:43:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Aec8XB71v4ze for ; Sat, 25 Aug 2012 23:43:18 -0700 (PDT) Received: from hwsga01-in.huaweimarine.com (unknown [58.251.153.223]) by ietfa.amsl.com (Postfix) with ESMTP id 3265421F842B for ; Sat, 25 Aug 2012 23:43:16 -0700 (PDT) Received: from szxpml202-edg.exmail.huawei.com ([172.17.1.119]) by hwsga01-in.huaweimarine.com (MOS 4.1.3-GA) with ESMTP id ADE71801; Sun, 26 Aug 2012 14:43:09 +0800 X-Mirapoint-Received-SPF: 172.17.1.119 szxpml202-edg.exmail.huawei.com 5 none From: Roni Even To: "clue@ietf.org" Thread-Topic: [clue] I-D Action: draft-ietf-clue-telepresence-use-cases-04.txt Thread-Index: AQHNg1WmLhTupKNVKUiBphrH+dAOSZdrpQy2 Date: Sun, 26 Aug 2012 06:43:07 +0000 Message-ID: <760B7D45D1EFF74988DBF5C2122830C2818014@szxpml504-mbs.exmail.huawei.com> References: <20120826064009.1615.88387.idtracker@ietfa.amsl.com> In-Reply-To: <20120826064009.1615.88387.idtracker@ietfa.amsl.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.60] 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-telepresence-use-cases-04.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: Sun, 26 Aug 2012 06:43:18 -0000 Hi, I added a new section (3.8) with the multi presentations, telemedicine use = case based on the IETF84 summary. Roni ________________________________________ From: clue-bounces@ietf.org [clue-bounces@ietf.org] on behalf of internet-d= rafts@ietf.org [internet-drafts@ietf.org] Sent: Sunday, August 26, 2012 9:40 AM To: i-d-announce@ietf.org Cc: clue@ietf.org Subject: [clue] I-D Action: draft-ietf-clue-telepresence-use-cases-04.txt 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 tElepres= ence Working Group of the IETF. Title : Use Cases for Telepresence Multi-streams Author(s) : Allyn Romanow Stephen Botzko Mark Duckworth Roni Even Iformata Communications Filename : draft-ietf-clue-telepresence-use-cases-04.txt Pages : 17 Date : 2012-08-25 Abstract: Telepresence conferencing systems seek to create the sense of really being present for the participants. A number of techniques for handling audio and video streams are used to create this experience. When these techniques are not similar, interoperability between different systems is difficult at best, and often not possible. Conveying information about the relationships between multiple streams of media would allow senders and receivers to make choices to allow telepresence systems to interwork. This memo describes the most typical and important use cases for sending multiple streams in a telepresence conference. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-clue-telepresence-use-cases There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-clue-telepresence-use-cases-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-clue-telepresence-use-cases-0= 4 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue= From christer.holmberg@ericsson.com Sun Aug 26 12:10: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 856EF21F8513; Sun, 26 Aug 2012 12:10:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.166 X-Spam-Level: X-Spam-Status: No, score=-6.166 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9NN0C25xzo7T; Sun, 26 Aug 2012 12:10:50 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 48DF121F8517; Sun, 26 Aug 2012 12:10:48 -0700 (PDT) X-AuditID: c1b4fb2d-b7fea6d000002ccb-86-503a74b76c43 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id A3.C4.11467.7B47A305; Sun, 26 Aug 2012 21:10:47 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.99]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Sun, 26 Aug 2012 21:10:46 +0200 From: Christer Holmberg To: "'internet-drafts@ietf.org'" , "i-d-announce@ietf.org" Date: Sun, 26 Aug 2012 21:10:46 +0200 Thread-Topic: [clue] I-D Action: draft-ietf-clue-telepresence-use-cases-04.txt Thread-Index: Ac2DVaX4Wyy5G/HvQzqDh+09clOPpwAZyPAg Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585340A1E3A91@ESESSCMS0356.eemea.ericsson.se> References: <20120826064009.1615.88387.idtracker@ietfa.amsl.com> In-Reply-To: <20120826064009.1615.88387.idtracker@ietfa.amsl.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+NgFrrOLMWRmVeSWpSXmKPExsUyM+Jvre72EqsAg6fbJSz2n7rMbLFk13Nm iw93cx2YPZYs+ckUwBjFZZOSmpNZllqkb5fAldG7fyV7wVGJisa3n5gaGLuEuxg5OSQETCT2 nD3LBGGLSVy4t56ti5GLQ0jgFKPE9d8/WCCcBYwSrR9mM3cxcnCwCVhIdP/TBmkQEciT2L/2 DhuIzSygLPG1YRPYIBYBVYnWm9sZQWxhAV+JN3MOsEDUB0hM+vmBFcI2kph3aA47iM0rEC5x es5asHohAQeJyXvnMYPYnAKOEq1HX4PNZAQ67vupNUwQu8Qlbj2ZD3W0gMSSPeeZIWxRiZeP /7FC1ItK3GlfzwhRryOxYPcnqDu1JZYtfM0MsVdQ4uTMJywTGMVmIRk7C0nLLCQts5C0LGBk WcUonJuYmZNebqiXWpSZXFycn6dXnLqJERg5B7f81t3BeOqcyCFGaQ4WJXFerqT9/kIC6Ykl qdmpqQWpRfFFpTmpxYcYmTg4pRoYfYvDWzecrY7daLOz7b9CmeD6bSecGi5L1wok6WcUfPP6 WFttrilkkexofqzphVlqbur9nd/s0k9VGu/6KD+xuuJ1gPHRNTX6SkrCKqv7v/+t7/J10tvc s+CaYuC2nxYrfs12qXr/KeDqAlVdqe6dp5bscl9aIBbi2DI5PfYev+ikaW+q/7gqsRRnJBpq MRcVJwIAUVhLw2oCAAA= Cc: "clue@ietf.org" Subject: Re: [clue] I-D Action: draft-ietf-clue-telepresence-use-cases-04.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: Sun, 26 Aug 2012 19:10:52 -0000 Hi, A few questions: Q_GENERAL: As some of you know (I had a discussion with Roni about this just some days= ago), people and working groups sometimes have different understandings of= "media stream". So, what does media stream mean in the context of this document? A) A single media flow B) Media possible from multiple sources (but, in SDP language, still associ= ated with a single m- line)? C) Something else? Q_3_1: In chapter 3.1, why is it important that both sites have the same number of= displays? AFAIK, what is important is that they use the same number of media streams. Q_3_5: In section 3.5, what is meant by the following text? "(We are not here talking about legacy systems, but rather systems built t= o=20 participate in such a conference, although they are single stream only.)" Does it mean that, eventhough a system is single stream only, it still has = to support CLUE? Regards, Christer=20 -----Original Message----- From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of int= ernet-drafts@ietf.org Sent: 26. elokuuta 2012 9:40 To: i-d-announce@ietf.org Cc: clue@ietf.org Subject: [clue] I-D Action: draft-ietf-clue-telepresence-use-cases-04.txt 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 tElepres= ence Working Group of the IETF. Title : Use Cases for Telepresence Multi-streams Author(s) : Allyn Romanow Stephen Botzko Mark Duckworth Roni Even Iformata Communications Filename : draft-ietf-clue-telepresence-use-cases-04.txt Pages : 17 Date : 2012-08-25 Abstract: Telepresence conferencing systems seek to create the sense of really being present for the participants. A number of techniques for handling audio and video streams are used to create this experience. When these techniques are not similar, interoperability between different systems is difficult at best, and often not possible. Conveying information about the relationships between multiple streams of media would allow senders and receivers to make choices to allow telepresence systems to interwork. This memo describes the most typical and important use cases for sending multiple streams in a telepresence conference. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-clue-telepresence-use-cases There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-clue-telepresence-use-cases-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-clue-telepresence-use-cases-0= 4 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue From mary.ietf.barnes@gmail.com Mon Aug 27 11:35: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 784A321F8557 for ; Mon, 27 Aug 2012 11:35:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.689 X-Spam-Level: X-Spam-Status: No, score=-102.689 tagged_above=-999 required=5 tests=[AWL=-0.757, 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bZ8aTNzElyKJ for ; Mon, 27 Aug 2012 11:35:30 -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 E2F4A21F8512 for ; Mon, 27 Aug 2012 11:35:29 -0700 (PDT) Received: by lbky2 with SMTP id y2so2093878lbk.31 for ; Mon, 27 Aug 2012 11:35:28 -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=lasJbtj96yrYDiwoz/Clnn98pgmdntdhXMeKOrKrhZk=; b=uRttTEAyBvfSf+XGChe0fnxdFaiGvjgRvcakqmdkthYJPKVIPsvh33ssMrCqAMiuY5 kC/9kbOZEg89UWR6JDLxty5jmI4UFj+ZKDYrsrJkT/wJRJ9kPh7UMWC6jr/rlvE8oBCz bEDqK4l3hh9rG6QwyHfHrHEO3ySZXA7DU7GiUQRLM9x3uleYPtPD+OvMQnYHAlInODuD 9ntsniWvpscC/GJnAL+Tgi903eTZJFQRtShm5/nLvvdoYxjfYtVvB8p+FQ2HZ05UmU7b V6Z4wLdUYS8WqhVYqWq5X5pTjXBOJq0Go3l0yBMvkKVmK3vdDLY2evrNfjUu8juEOemj QtZg== MIME-Version: 1.0 Received: by 10.112.48.231 with SMTP id p7mr7006218lbn.7.1346092528733; Mon, 27 Aug 2012 11:35:28 -0700 (PDT) Received: by 10.112.17.202 with HTTP; Mon, 27 Aug 2012 11:35:28 -0700 (PDT) In-Reply-To: <50242759.6010909@alum.mit.edu> References: <8A527E21B95EF842BC0E952D6E82297747DA1D4A@szxeml527-mbx.china.huawei.com> <8A527E21B95EF842BC0E952D6E82297747DA1F8A@szxeml527-mbx.china.huawei.com> <50114600.3050406@alum.mit.edu> <50121C0B.5080100@nteczone.com> <50174FEE.1080208@nteczone.com> <5021FCC7.6070304@nteczone.com> <502273E7.6040205@alum.mit.edu> <50230DDC.1020808@nteczone.com> <50242759.6010909@alum.mit.edu> Date: Mon, 27 Aug 2012 13:35:28 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=bcaec553ff3a028ed704c843977d Subject: Re: [clue] FW: New Version Notification for draft-xiao-clue-telemedical-use-case-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: Mon, 27 Aug 2012 18:35:32 -0000 --bcaec553ff3a028ed704c843977d Content-Type: text/plain; charset=ISO-8859-1 No one has responded, so I will chime in. We will need a detailed call flow document that shows how the CLUE use cases are realized. It would be very useful to have one or two flows that show the SIP details as well as other protocols that might be involved. For XCON, we included a flow of how XCON interacts with the MEDIACTRL protocols in the detailed call flow document (RFC 6504). We only did this at the beginning and not for each and every call flow. Calls flows are terribly tedious, but they are extremely helpful when folks are trying to understand the protocol and they are an excellent way to sanity check things and find gaps, so I don't think we can get away with not doing them. I personally think it would add *alot* of value to have some high level call flows (similar to what Rob did for the tutorial) in the framework document. We did this for XCON for the majority of the use cases (per RFC 5239). Note, that we had textual descriptions of what happened at each stage. In CLUE, we have had snippets of these in the various presentations but I would love someone to step forward and do these. These then feed very naturally into the detailed call flow document that has all the protocol details. Mary. On Thu, Aug 9, 2012 at 4:10 PM, Paul Kyzivat wrote: > On 8/8/12 6:09 PM, Christian Groves wrote: > >> Hello Paul, >> >> I think those enhanced call flows are necessary. >> > > What do others think? Shall we ask that the call flows (at least some of > them) include conference event package subscription and notifications and > bfcp setup and signaling? > > I agree that this may be necessary - probably not in every call flow, but > in cases where the use of those channels is necessary for the use case to > work. And how often that is depends on how much information we defer to > those protocols for. > > > I think we need to >> understand how the XCON concepts will map to those we've created in >> CLUE. I agree an initial invite can establish a CLUE and BFCP stream and >> conference event package but there are dependencies between the data >> that will be sent across them, i.e. an end point will use some data from >> one protocol to send data in another, i.e. the media information in XCON >> would be dependent on what captures were agreed via CLUE. So whilst they >> can be established at the same time there is actually some sequencing >> needed. AFAIK currently in XCON there is no concept of captures, so no >> ability to describe them. >> >> So coming back to the example to the issue below. If we believe that for >> a description of the endpoint that XCON should be used rather than our >> CLUE description "Attribute" we should state this in the CLUE framework >> draft as an aid to interoperability (although I'm not sure how labelling >> in multiple languages would work?), do we use or >> <**display-text> or? >> >> Regards, Christian >> > > Thanks, > Paul > > > On 9/08/2012 12:12 AM, Paul Kyzivat wrote: >> >>> On 8/7/12 10:44 PM, Christian Groves wrote: >>> >>>> Hello Mary, >>>> >>>> I guess the reason why is the same reason why the media streams will >>>> likely be set up after CLUE. There could be potentially a large possible >>>> set of captures/configurations that you want to narrow down before you >>>> start assigning resources to them. You want to have enough information >>>> associated with the captures so that an educated decision can be made >>>> about whether to accept/use one. I don't think its enough just to assume >>>> that XCON will handle these things. >>>> >>> >>> I'm not sure I understand this. >>> >>> ISTM that the initial INVITE to set up a CLUE call could contain an >>> offer of: >>> - an initial audio and video stream >>> - a CLUE protocol stream >>> - a bfcp stream >>> - indication of support for the conf event package >>> >>> As soon as the initial answer is sent, if not sooner, the CLUE stream >>> and the bfcp stream can be opened, and a subscribe sent for the conf >>> event package. Shortly thereafter, CLUE advertisements can be sent in >>> both directions and a first notification for the conf event package >>> can be sent. >>> >>> Then, both the advertisement and the conf event state can be used for >>> constructing the CLUE configuration message. >>> >>> Maybe we should create an enhanced call flow that shows all of that. >>> >>> Thanks, >>> Paul >>> >>> Regards, Christian >>>> >>>> On 2/08/2012 3:48 AM, Mary Barnes wrote: >>>> >>>>> (As an individual) >>>>> >>>>> Why is it that you think XCON signaling with come after initial CLUE >>>>> signaling? It is certainly possible to get an XCON notification before >>>>> doing any CLUE signaling. CLUE will be reusing existing signaling >>>>> protocols to establish the basic session - that would include using >>>>> basic SIP conferencing and could include the use of XCON. >>>>> >>>>> Mary. >>>>> >>>>> On Mon, Jul 30, 2012 at 10:24 PM, Christian Groves >>>>> >>>>> >> >>>>> wrote: >>>>> >>>>> Hello Espen, >>>>> >>>>> The issue that I see is that the conference event package or XCON >>>>> would come after the initial CLUE signalling. You may want to >>>>> chose captures based on this high level information before XCON >>>>> etc is established. However I think the main point is that we need >>>>> to be a little more detailed when we describe the use of these >>>>> fields if people are even now proposing different uses. >>>>> >>>>> Regards, Christian >>>>> >>>>> >>>>> On 30/07/2012 11:46 PM, Espen Berger (espeberg) wrote: >>>>> >>>>> Hi Christian >>>>> >>>>> If a consumer want to learn about information that's on the >>>>> level of " like "Teleconference Room 2, Beijing" I think its >>>>> natural to look into conference event package or XCON. >>>>> >>>>> In the medical case the description attribute will have values >>>>> like "x-ray" or "CT-scan", "Operation", which is needed since >>>>> other captures attributes will have the same values. >>>>> >>>>> -Espen >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: clue-bounces@ietf.org >>>>> [mailto:clue-bounces@ietf.org **] >>>>> On Behalf Of Christian Groves >>>>> Sent: 27. juli 2012 06:42 >>>>> To: clue@ietf.org >>>>> Subject: Re: [clue] FW: New Version Notification for >>>>> draft-xiao-clue-telemedical-**use-case-00.txt >>>>> >>>>> Hello Paul, >>>>> >>>>> I think have a enumeration for very specific capabilities woul >>>>> dbe hard but I think there may be some common ones to many >>>>> conferencing / telepresence scenarios. In the discussion of >>>>> this topic I think that perhaps the "description" attribute we >>>>> have today may be too broad. I was thinking it would be used >>>>> for something like "Teleconference Room 2, Beijing" but it >>>>> seems there's proposals to use this for functional level >>>>> things like "speaker etc". >>>>> >>>>> Regards, Christian >>>>> >>>>> On 26/07/2012 11:28 PM, Paul Kyzivat wrote: >>>>> >>>>> [as individual] >>>>> >>>>> On 7/26/12 2:51 AM, Xiaojing wrote: >>>>> >>>>> Hi Espen, >>>>> >>>>> Please see my response inline. >>>>> >>>>> Regards, >>>>> Lennard >>>>> >>>>> -----Original Message----- >>>>> From: Espen Berger (espeberg) >>>>> [mailto:espeberg@cisco.com ] >>>>> Sent: Wednesday, July 25, 2012 11:19 PM >>>>> To: Xiaojing; clue@ietf.org >>>>> Subject: RE: [clue] FW: New Version Notification for >>>>> draft-xiao-clue-telemedical-**use-case-00.txt >>>>> >>>>> Thanks for sharing the use case. I had a similar use >>>>> case in mind, >>>>> advanced lecture type calls mainly focusing on P2P >>>>> with multiple >>>>> presentation streams. >>>>> >>>>> My assumption for an advanced use case like this is >>>>> each capture has >>>>> at least a description field, e.g. 'x-ray' or >>>>> 'CT-scan', that can be >>>>> used by a manual operator to start and stop what to >>>>> receive. This use >>>>> case explains why we need descriptions for both >>>>> capture-scenes and >>>>> captures. >>>>> >>>>> [Xiao Jing] I share the same thinking on the >>>>> description field with >>>>> you. The different presentations need to be identified >>>>> from each >>>>> other. A straightforward way is to add description >>>>> tags to them. >>>>> >>>>> I think a textual description is the place to start. >>>>> It would be hard to start defining a machine-processable >>>>> enumeration >>>>> of application-specific categories. >>>>> >>>>> We already have the proposal for such a mechanism. >>>>> This use case simply reinforces the need for that mechanism. >>>>> >>>>> Questions >>>>> * Do you assume manual or automatic selection of >>>>> presentation streams? >>>>> [Xiao Jing] In my initial thinking, in the use case it >>>>> is the surgeon >>>>> and endpoint users who decide which presentation >>>>> streams to be sent >>>>> and displayed. Thus it is necessary to identify the >>>>> presentations. >>>>> * How do you decide which presentation streams are >>>>> important? What if >>>>> you offer three presentation streams and I can only >>>>> receive one, how >>>>> do I decide which of them to receive? >>>>> [Xiao Jing] I assume that the users can differentiate >>>>> the streams and >>>>> then decide which to receive. In this case, if the >>>>> user knows exactly >>>>> what the stream is about, he can decide without additional >>>>> information from the provider. But I also think we can >>>>> introduced >>>>> kind of priority concept into it. The "content" >>>>> attribute could be a >>>>> good place to include this idea. In my memory, >>>>> Christian and Paul are >>>>> working on this issue, and I'll try to inform them to >>>>> take this into >>>>> consideration. >>>>> * Have you identified additional meta-information to >>>>> the CLUE >>>>> framework needed to describe the information you have >>>>> in mind writing >>>>> up the use case. >>>>> [Xiao Jing] In this early stage, I'm just trying to >>>>> draw concern >>>>> about the necessity of having multiple presentation >>>>> streams. I think >>>>> the current framework can cover all the new >>>>> requirements coming up >>>>> with this use case at ease. >>>>> >>>>> I'm not sure whether 'priority' has been brought up on >>>>> this public >>>>> list or not. >>>>> >>>>> But it is my thought that we need a numeric priority value per >>>>> capture, that can be used by the recipient when it doesn't >>>>> have the >>>>> resources to render even the smallest entry from each >>>>> scene. *That* >>>>> would provide a way for the receiving equipment to provide >>>>> a default >>>>> rendering. Some endpoints might also provide a gui for the >>>>> end users >>>>> to manually configure based on descriptions. >>>>> >>>>> The numeric priority could be used to indicate that the >>>>> presentation >>>>> is more important than the speaker, or visa versa. And it >>>>> can be used >>>>> to indicate a relative priority among presentations. Etc. >>>>> >>>>> Thanks, >>>>> Paul >>>>> >>>>> Regards >>>>> >>>>> -Espen >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: clue-bounces@ietf.org >>>>> >>>>> [mailto:clue-bounces@ietf.org >>>>> **] On Behalf >>>>> Of Xiaojing >>>>> Sent: 25. juli 2012 04:40 >>>>> To: clue@ietf.org >>>>> Subject: [clue] FW: New Version Notification for >>>>> draft-xiao-clue-telemedical-**use-case-00.txt >>>>> >>>>> Hi all, >>>>> >>>>> I've submitted a telemedical use case, which addresses >>>>> the use of >>>>> Telepresence into medical scenarios. >>>>> >>>>> I think this use case is valid to add another >>>>> application field where >>>>> Telepresence can be used. >>>>> So I'd like to suggest adding this use case into the >>>>> current use case >>>>> document. >>>>> >>>>> Also, along with this use case, some new requirements >>>>> might come up, >>>>> e.g. the requirement to support multiple presentation >>>>> streams, which >>>>> might be considered into the requirement draft. >>>>> >>>>> Best regards, >>>>> Lennard >>>>> >>>>> -----Original Message----- >>>>> From: internet-drafts@ietf.org >>>>> > >>>>> [mailto:internet-drafts@ietf.**org >>>>> >] >>>>> Sent: Monday, July 09, 2012 11:13 AM >>>>> To: Xiaojing >>>>> Cc: Roni even >>>>> Subject: New Version Notification for >>>>> draft-xiao-clue-telemedical-**use-case-00.txt >>>>> >>>>> >>>>> A new version of I-D, >>>>> draft-xiao-clue-telemedical-**use-case-00.txt >>>>> has been successfully submitted by Lennard Xiao and >>>>> posted to the >>>>> IETF repository. >>>>> >>>>> Filename: draft-xiao-clue-telemedical-**use-case >>>>> Revision: 00 >>>>> Title: Use Case for Telemedical with Multi-streams >>>>> Creation date: 2012-07-06 >>>>> WG ID: Individual Submission >>>>> Number of pages: 5 >>>>> URL: >>>>> http://www.ietf.org/internet-**drafts/draft-xiao-clue-** >>>>> telemedical-use-c >>>>> ase-00.txt >>>>> Status: >>>>> http://datatracker.ietf.org/**doc/draft-xiao-clue-** >>>>> telemedical-use-case >>>>> Htmlized: >>>>> http://tools.ietf.org/html/**draft-xiao-clue-telemedical-**use-case-00 >>>>> >>>>> >>>>> Abstract: >>>>> This memo presenst a telemedicine use case where >>>>> multiple >>>>> presentation streams are used for conveying >>>>> different information in >>>>> parallel to the main video from the surgery room >>>>> >>>>> >>>>> >>>>> >>>>> 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 >>>>> >>>>> ______________________________**_________________ >>>>> 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 > --bcaec553ff3a028ed704c843977d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable No one has responded, so I will chime in. =A0We will need a detailed call f= low document that shows how the CLUE use cases are realized. =A0It would be= very useful to have one or two flows that show the SIP details as well as = other protocols that might be involved. =A0For XCON, we included a flow of = how XCON interacts with the MEDIACTRL protocols in the detailed call flow d= ocument (RFC 6504). =A0We only did this at the beginning and not for each a= nd every call flow.=A0

Calls flows are terribly tedious, but they are extremely hel= pful when folks are trying to understand the protocol and they are an excel= lent way to sanity check things and find gaps, so I don't think we can = get away with not doing them. =A0 I personally think it would add *alot* of= value to have some high level call flows (similar to what Rob did for the = tutorial) in the framework document. =A0We did this for XCON for the majori= ty of the use cases (per RFC 5239). =A0Note, that we had textual descriptio= ns of what happened at each stage. In CLUE, we have had snippets of these i= n the various presentations but I would love someone to step forward and do= these. =A0These then feed very naturally into the detailed call flow docum= ent that has all the protocol details. =A0=A0

Mary.=A0

On= Thu, Aug 9, 2012 at 4:10 PM, Paul Kyzivat <pkyzivat@alum.mit.edu&= gt; wrote:
On 8/8/12 6:09 PM, Christi= an Groves wrote:
Hello Paul,

I think those enhanced call flows are necessary.

What do others think? Shall we ask that the call flows (at least some of th= em) include conference event package subscription and notifications and bfc= p setup and signaling?

I agree that this may be necessary - probably not in every call flow, but i= n cases where the use of those channels is necessary for the use case to wo= rk. And how often that is depends on how much information we defer to those= protocols for.


I think we need to
understand how the XCON concepts will map to those we've created in
CLUE. I agree an initial invite can establish a CLUE and BFCP stream and conference event package but there are dependencies between the data
that will be sent across them, i.e. an end point will use some data from one protocol to send data in another, i.e. the media information in XCON would be dependent on what captures were agreed via CLUE. So whilst they can be established at the same time there is actually some sequencing
needed. AFAIK currently in XCON there is no concept of captures, so no
ability to describe them.

So coming back to the example to the issue below. If we believe that for a description of the endpoint that XCON should be used rather than our
CLUE description "Attribute" we should state this in the CLUE fra= mework
draft as an aid to interoperability (although I'm not sure how labellin= g
in multiple languages would work?), do we use <users><display-text= > or
<conference-description><display-text> or?

Regards, Christian

=A0 =A0 =A0 =A0 Thanks,
=A0 =A0 =A0 =A0 Paul


On 9/08/2012 12:12 AM, Paul Kyzivat wrote:
On 8/7/12 10:44 PM, Christian Groves wrote:
Hello Mary,

I guess the reason why is the same reason why the media streams will
likely be set up after CLUE. There could be potentially a large possible set of captures/configurations that you want to narrow down before you
start assigning resources to them. You want to have enough information
associated with the captures so that an educated decision can be made
about whether to accept/use one. I don't think its enough just to assum= e
that XCON will handle these things.

I'm not sure I understand this.

ISTM that the initial INVITE to set up a CLUE call could contain an
offer of:
- an initial audio and video stream
- a CLUE protocol stream
- a bfcp stream
- indication of support for the conf event package

As soon as the initial answer is sent, if not sooner, the CLUE stream
and the bfcp stream can be opened, and a subscribe sent for the conf
event package. Shortly thereafter, CLUE advertisements can be sent in
both directions and a first notification for the conf event package
can be sent.

Then, both the advertisement and the conf event state can be used for
constructing the CLUE configuration message.

Maybe we should create an enhanced call flow that shows all of that.

Thanks,
Paul

Regards, Christian

On 2/08/2012 3:48 AM, Mary Barnes wrote:
(As an individual)

Why is it that you think XCON signaling with come after initial CLUE
signaling? It is certainly possible to get an XCON notification before
doing any CLUE signaling. CLUE will be reusing existing signaling
protocols to establish the basic session - that would include using
basic SIP conferencing and could include the use of XCON.

Mary.

On Mon, Jul 30, 2012 at 10:24 PM, Christian Groves
<Chri= stian.Groves@nteczone.com <mailto:Christian.Groves@nteczone.com&g= t;>
wrote:

Hello Espen,

The issue that I see is that the conference event package or XCON
would come after the initial CLUE signalling. You may want to
chose captures based on this high level information before XCON
etc is established. However I think the main point is that we need
to be a little more detailed when we describe the use of these
fields if people are even now proposing different uses.

Regards, Christian


On 30/07/2012 11:46 PM, Espen Berger (espeberg) wrote:

Hi Christian

If a consumer want to learn about information that's on the
level of " like "Teleconference Room 2, Beijing" I think its=
natural to look into conference event package or XCON.

In the medical case the description attribute will have values
like "x-ray" or "CT-scan", "Operation", which= is needed since
other captures attributes will have the same values.

-Espen


-----Original Message-----
From: clue-bounc= es@ietf.org <mailto:clue-bounces@ietf.org>
[mailto:clue-bou= nces@ietf.org <mailto:clue-bounces@ietf.org>]
On Behalf Of Christian Groves
Sent: 27. juli 2012 06:42
To: clue@ietf.org &l= t;mailto:clue@ietf.org>
Subject: Re: [clue] FW: New Version Notification for
draft-xiao-clue-telemedical-use-case-00.txt

Hello Paul,

I think have a enumeration for very specific capabilities woul
dbe hard but I think there may be some common ones to many
conferencing / telepresence scenarios. In the discussion of
this topic I think that perhaps the "description" attribute we have today may be too broad. I was thinking it would be used
for something like "Teleconference Room 2, Beijing" but it
seems there's proposals to use this for functional level
things like "speaker etc".

Regards, Christian

On 26/07/2012 11:28 PM, Paul Kyzivat wrote:

[as individual]

On 7/26/12 2:51 AM, Xiaojing wrote:

Hi Espen,

Please see my response inline.

Regards,
Lennard

-----Original Message-----
From: Espen Berger (espeberg)
[mailto:espeberg@ci= sco.com <mailto:espeberg@cisco.com>]
Sent: Wednesday, July 25, 2012 11:19 PM
To: Xiaojing; clue@ietf.= org <mailto:clue@= ietf.org>
Subject: RE: [clue] FW: New Version Notification for
draft-xiao-clue-telemedical-use-case-00.txt

Thanks for sharing the use case. I had a similar use
case in mind,
advanced lecture type calls mainly focusing on P2P
with multiple
presentation streams.

My assumption for an advanced use case like this is
each capture has
at least a description field, e.g. 'x-ray' or
'CT-scan', that can be
used by a manual operator to start and stop what to
receive. This use
case explains why we need descriptions for both
capture-scenes and
captures.

[Xiao Jing] I share the same thinking on the
description field with
you. The different presentations need to be identified
from each
other. A straightforward way is to add description
tags to them.

I think a textual description is the place to start.
It would be hard to start defining a machine-processable
enumeration
of application-specific categories.

We already have the proposal for such a mechanism.
This use case simply reinforces the need for that mechanism.

Questions
* Do you assume manual or automatic selection of
presentation streams?
[Xiao Jing] In my initial thinking, in the use case it
is the surgeon
and endpoint users who decide which presentation
streams to be sent
and displayed. Thus it is necessary to identify the
presentations.
* How do you decide which presentation streams are
important? What if
you offer three presentation streams and I can only
receive one, how
do I decide which of them to receive?
[Xiao Jing] I assume that the users can differentiate
the streams and
then decide which to receive. In this case, if the
user knows exactly
what the stream is about, he can decide without additional
information from the provider. But I also think we can
introduced
kind of priority concept into it. The "content"
attribute could be a
good place to include this idea. In my memory,
Christian and Paul are
working on this issue, and I'll try to inform them to
take this into
consideration.
* Have you identified additional meta-information to
the CLUE
framework needed to describe the information you have
in mind writing
up the use case.
[Xiao Jing] In this early stage, I'm just trying to
draw concern
about the necessity of having multiple presentation
streams. I think
the current framework can cover all the new
requirements coming up
with this use case at ease.

I'm not sure whether 'priority' has been brought up on
this public
list or not.

But it is my thought that we need a numeric priority value per
capture, that can be used by the recipient when it doesn't
have the
resources to render even the smallest entry from each
scene. *That*
would provide a way for the receiving equipment to provide
a default
rendering. Some endpoints might also provide a gui for the
end users
to manually configure based on descriptions.

The numeric priority could be used to indicate that the
presentation
is more important than the speaker, or visa versa. And it
can be used
to indicate a relative priority among presentations. Etc.

Thanks,
Paul

Regards

-Espen


-----Original Message-----
From: clue-bounc= es@ietf.org
<mailto:clue-= bounces@ietf.org>
[mailto:clue-bou= nces@ietf.org
<mailto:clue-= bounces@ietf.org>] On Behalf
Of Xiaojing
Sent: 25. juli 2012 04:40
To: clue@ietf.org &l= t;mailto:clue@ietf.org>
Subject: [clue] FW: New Version Notification for
draft-xiao-clue-telemedical-use-case-00.txt

Hi all,

I've submitted a telemedical use case, which addresses
the use of
Telepresence into medical scenarios.

I think this use case is valid to add another
application field where
Telepresence can be used.
So I'd like to suggest adding this use case into the
current use case
document.

Also, along with this use case, some new requirements
might come up,
e.g. the requirement to support multiple presentation
streams, which
might be considered into the requirement draft.

Best regards,
Lennard

-----Original Message-----
From: interne= t-drafts@ietf.org
<mailto:in= ternet-drafts@ietf.org>
[mailto:inter= net-drafts@ietf.org
<mailto:in= ternet-drafts@ietf.org>]
Sent: Monday, July 09, 2012 11:13 AM
To: Xiaojing
Cc: Roni even
Subject: New Version Notification for
draft-xiao-clue-telemedical-use-case-00.txt


A new version of I-D,
draft-xiao-clue-telemedical-use-case-00.txt
has been successfully submitted by Lennard Xiao and
posted to the
IETF repository.

Filename: draft-xiao-clue-telemedical-use-case
Revision: 00
Title: Use Case for Telemedical with Multi-streams
Creation date: 2012-07-06
WG ID: Individual Submission
Number of pages: 5
URL:
http://www.ietf.org/internet-drafts/draft-x= iao-clue-telemedical-use-c
ase-00.txt
Status:
http://datatracker.ietf.org/doc/draft-xiao-c= lue-telemedical-use-case
Htmlized:
http://tools.ietf.org/html/draft-xiao-clue-tel= emedical-use-case-00


Abstract:
This memo presenst a telemedicine use case where
multiple
presentation streams are used for conveying
different information in
parallel to the main video from the surgery room




The IETF Secretariat
_______________________________________________
clue mailing list
clue@ietf.org <ma= ilto:clue@ietf.org&g= t;
ht= tps://www.ietf.org/mailman/listinfo/clue
_______________________________________________
clue mailing list
clue@ietf.org <ma= ilto:clue@ietf.org&g= t;
ht= tps://www.ietf.org/mailman/listinfo/clue

_______________________________________________
clue mailing list
clue@ietf.org <ma= ilto:clue@ietf.org&g= t;
ht= tps://www.ietf.org/mailman/listinfo/clue

_______________________________________________
clue mailing list
clue@ietf.org <ma= ilto:clue@ietf.org&g= t;
ht= tps://www.ietf.org/mailman/listinfo/clue


_______________________________________________
clue mailing list
clue@ietf.org <ma= ilto:clue@ietf.org&g= t;
ht= tps://www.ietf.org/mailman/listinfo/clue



_______________________________________________
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


_______________________________________________
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

--bcaec553ff3a028ed704c843977d-- From trac+clue@trac.tools.ietf.org Mon Aug 27 15:00: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 B5C6811E8091 for ; Mon, 27 Aug 2012 15:00:52 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JfBJxuTZgm1T for ; Mon, 27 Aug 2012 15:00:51 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id AC35F11E808A for ; Mon, 27 Aug 2012 15:00:51 -0700 (PDT) Received: from localhost ([127.0.0.1]:42047 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1T67MI-00087v-Df; Tue, 28 Aug 2012 00:00:34 +0200 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: Mon, 27 Aug 2012 22:00:34 -0000 X-URL: http://tools.ietf.org/wg/clue/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/clue/trac/ticket/12 Message-ID: <068.d15391187319f8b7b89764b056e281a7@trac.tools.ietf.org> X-Trac-Ticket-ID: 12 X-SA-Exim-Connect-IP: 127.0.0.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 grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: mary.barnes@polycom.com, pkyzivat@alum.mit.edu, Resent-Message-Id: <20120827220051.AC35F11E808A@ietfa.amsl.com> Resent-Date: Mon, 27 Aug 2012 15:00:51 -0700 (PDT) Resent-From: trac+clue@trac.tools.ietf.org Cc: clue@ietf.org Subject: [clue] #12: Signaling: what data can be carried in SDP? 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: Mon, 27 Aug 2012 22:00:52 -0000 #12: Signaling: what data can be carried in SDP? -- --------------------------------+--------------------------- Reporter: mary.ietf.barnes@… | Owner: clue-chairs@… Type: task | Status: new Priority: major | Milestone: milestone1 Component: charter | Version: 1.0 Severity: - | Keywords: --------------------------------+--------------------------- Ticket URL: clue From trac+clue@trac.tools.ietf.org Mon Aug 27 15:01: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 EA13521E8037 for ; Mon, 27 Aug 2012 15:01:22 -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, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rq35DMjXd+Rs for ; Mon, 27 Aug 2012 15:01:22 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id F3BA421E803A for ; Mon, 27 Aug 2012 15:01:21 -0700 (PDT) Received: from localhost ([127.0.0.1]:42114 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1T67N0-0005vo-Uk; Tue, 28 Aug 2012 00:01:18 +0200 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: Mon, 27 Aug 2012 22:01:18 -0000 X-URL: http://tools.ietf.org/wg/clue/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/clue/trac/ticket/13 Message-ID: <068.5c6abb800fdf8cf51ba44786e2a839e4@trac.tools.ietf.org> X-Trac-Ticket-ID: 13 X-SA-Exim-Connect-IP: 127.0.0.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 grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: mary.barnes@polycom.com, pkyzivat@alum.mit.edu, Resent-Message-Id: <20120827220121.F3BA421E803A@ietfa.amsl.com> Resent-Date: Mon, 27 Aug 2012 15:01:21 -0700 (PDT) Resent-From: trac+clue@trac.tools.ietf.org Cc: clue@ietf.org Subject: [clue] #13: Signaling: What data needs to be in CLUE specific signaling? 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: Mon, 27 Aug 2012 22:01:23 -0000 #13: Signaling: What data needs to be in CLUE specific signaling? -- --------------------------------+--------------------------- Reporter: mary.ietf.barnes@… | Owner: clue-chairs@… Type: task | Status: new Priority: blocker | Milestone: milestone1 Component: charter | Version: Severity: - | Keywords: --------------------------------+--------------------------- Ticket URL: clue From trac+clue@trac.tools.ietf.org Mon Aug 27 15:02: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 D2B5F21F842C for ; Mon, 27 Aug 2012 15:02:51 -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, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TaKoPcPvR8UH for ; Mon, 27 Aug 2012 15:02:51 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 504C321F842B for ; Mon, 27 Aug 2012 15:02:51 -0700 (PDT) Received: from localhost ([127.0.0.1]:42217 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1T67OB-0005EC-HT; Tue, 28 Aug 2012 00:02:31 +0200 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: Mon, 27 Aug 2012 22:02:31 -0000 X-URL: http://tools.ietf.org/wg/clue/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/clue/trac/ticket/14 Message-ID: <068.890588ccdb9d1a0b74f5999dd9ddcd35@trac.tools.ietf.org> X-Trac-Ticket-ID: 14 X-SA-Exim-Connect-IP: 127.0.0.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 grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: mary.barnes@polycom.com, pkyzivat@alum.mit.edu, Resent-Message-Id: <20120827220251.504C321F842B@ietfa.amsl.com> Resent-Date: Mon, 27 Aug 2012 15:02:51 -0700 (PDT) Resent-From: trac+clue@trac.tools.ietf.org Cc: clue@ietf.org Subject: [clue] #14: How do we transport the CLUE information? 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: Mon, 27 Aug 2012 22:02:52 -0000 #14: How do we transport the CLUE information? What transport protocol should be used for the CLUE specific signaling information? -- --------------------------------+--------------------------- Reporter: mary.ietf.barnes@… | Owner: clue-chairs@… Type: task | Status: new Priority: blocker | Milestone: milestone1 Component: charter | Version: 1.0 Severity: - | Keywords: --------------------------------+--------------------------- Ticket URL: clue From trac+clue@trac.tools.ietf.org Mon Aug 27 15:03: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 DCE0221F843A for ; Mon, 27 Aug 2012 15:03:31 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XfjSOrsfGUFQ for ; Mon, 27 Aug 2012 15:03:31 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 4D76921F842B for ; Mon, 27 Aug 2012 15:03:31 -0700 (PDT) Received: from localhost ([127.0.0.1]:42266 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1T67P6-0007j2-Kt; Tue, 28 Aug 2012 00:03:28 +0200 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: Mon, 27 Aug 2012 22:03:28 -0000 X-URL: http://tools.ietf.org/wg/clue/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/clue/trac/ticket/12#comment:1 Message-ID: <083.e0a0d1b8d9006b17e81b6d843cd7992a@trac.tools.ietf.org> References: <068.d15391187319f8b7b89764b056e281a7@trac.tools.ietf.org> X-Trac-Ticket-ID: 12 In-Reply-To: <068.d15391187319f8b7b89764b056e281a7@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.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 grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: mary.barnes@polycom.com, pkyzivat@alum.mit.edu, Resent-Message-Id: <20120827220331.4D76921F842B@ietfa.amsl.com> Resent-Date: Mon, 27 Aug 2012 15:03:31 -0700 (PDT) Resent-From: trac+clue@trac.tools.ietf.org Cc: clue@ietf.org Subject: Re: [clue] #12: Signaling: what data can be carried in SDP? 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: Mon, 27 Aug 2012 22:03:32 -0000 #12: Signaling: what data can be carried in SDP? Changes (by mary.ietf.barnes@…): * priority: major => blocker -- --------------------------------+---------------------------- Reporter: mary.ietf.barnes@… | Owner: clue-chairs@… Type: task | Status: new Priority: blocker | Milestone: milestone1 Component: charter | Version: 1.0 Severity: - | Resolution: Keywords: | --------------------------------+---------------------------- Ticket URL: clue From trac+clue@trac.tools.ietf.org Mon Aug 27 15:13: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 74D6711E8091 for ; Mon, 27 Aug 2012 15:13:35 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9u9LJ2L-fTNH for ; Mon, 27 Aug 2012 15:13:35 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id D66F311E808A for ; Mon, 27 Aug 2012 15:13:34 -0700 (PDT) Received: from localhost ([127.0.0.1]:42505 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1T67YZ-00039l-Mr; Tue, 28 Aug 2012 00:13:15 +0200 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: Mon, 27 Aug 2012 22:13:15 -0000 X-URL: http://tools.ietf.org/wg/clue/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/clue/trac/ticket/15 Message-ID: <068.5466264b635ccb586d60ce5b5ee027f9@trac.tools.ietf.org> X-Trac-Ticket-ID: 15 X-SA-Exim-Connect-IP: 127.0.0.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 grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: mary.barnes@polycom.com, pkyzivat@alum.mit.edu, Resent-Message-Id: <20120827221334.D66F311E808A@ietfa.amsl.com> Resent-Date: Mon, 27 Aug 2012 15:13:34 -0700 (PDT) Resent-From: trac+clue@trac.tools.ietf.org Cc: clue@ietf.org Subject: [clue] #15: What signaling protocol should be used for the CLUE information? 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: Mon, 27 Aug 2012 22:13:35 -0000 #15: What signaling protocol should be used for the CLUE information? Note, that this is separate from the question of the "transport layer protocol", although we have sometimes used the term "transport" for the signaling protocol. -- --------------------------------+--------------------------- Reporter: mary.ietf.barnes@… | Owner: clue-chairs@… Type: task | Status: new Priority: critical | Milestone: milestone1 Component: charter | Version: 1.0 Severity: - | Keywords: --------------------------------+--------------------------- Ticket URL: clue From mary.ietf.barnes@gmail.com Mon Aug 27 15:21: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 A887821E8034 for ; Mon, 27 Aug 2012 15:21:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.518 X-Spam-Level: X-Spam-Status: No, score=-103.518 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NT0EnLPQknTn for ; Mon, 27 Aug 2012 15:21:56 -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 D468311E808A for ; Mon, 27 Aug 2012 15:21:55 -0700 (PDT) Received: by lahm15 with SMTP id m15so3035893lah.31 for ; Mon, 27 Aug 2012 15:21:54 -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=SO6bfban6r/7/IioUw9sRcgybl8in92xOivBDUxYo70=; b=YbyDMBhSkeIODm117E8Hb0V/5DjG5Gl2WT/QoYwrT0eJ9eaTMtBnpfLUMKJGkF1/8j fk8ZiH+Fkvbw9h4CFpeXji9gZWPUoqb/b/p6SXr9RJagRhxzvoQZjbzwHucsxpLiRt5Q axkVYVxPPlmvxI6bM+4ajnU2OzG3QKjrOqOI0WnQiVtY6UNXli8FhHRc807dVJ7CUt4q 5NCCF2FzuMs1+RQmrnOZdtFB+0/LQ6g02YyLKQ0+9tmEUZ/CgxQeo72w+1DvoDfmZTKX IwaFGUPdifSp9jFKfMx2pG8gS+uYfOLAZN4dWfd/KUqU1kP3sMzxkB+HlgbDyfnoYjJu Bj8A== MIME-Version: 1.0 Received: by 10.112.46.135 with SMTP id v7mr7363118lbm.3.1346106114686; Mon, 27 Aug 2012 15:21:54 -0700 (PDT) Received: by 10.112.17.202 with HTTP; Mon, 27 Aug 2012 15:21:54 -0700 (PDT) Date: Mon, 27 Aug 2012 17:21:54 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=bcaec55240becbbf6104c846c01c Subject: [clue] New tickets related to signaling & transport solution 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, 27 Aug 2012 22:21:56 -0000 --bcaec55240becbbf6104c846c01c Content-Type: text/plain; charset=ISO-8859-1 Hi all, I created 4 new tickets based upon the "issues going forward" as summarized in the IETF-84 minutes: http://www.ietf.org/proceedings/84/minutes/minutes-84-clue.txt Note, that #12 and #13 can't be resolved until we have a data model on the table. However, we could start considering #14 & #15 (note that I've separated the decision about the signaling protocol from the transport protocol). This draft summarized various options for the "signaling protocol" (and not the transport protocol): http://www.ietf.org/id/draft-wenger-clue-transport-02.txt We didn't really make any progress on the topic really other than agreeing that SDP is not sufficient for signaling CLUE information: http://www.ietf.org/proceedings/83/minutes/minutes-83-clue.txt And, the call flow document we discussed at IETF-84 also gets into the signaling solution: http://www.ietf.org/id/draft-romanow-clue-call-flow-02.txt We are kind of in a chicken/egg situation right now since we don't have a "message schema" or "clue instance" data model developed. But, it might still be worthwhile to review the two above documents and at least eliminate some more of the options or agree some things. Regards, Mary. --bcaec55240becbbf6104c846c01c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all,

I created 4 new tickets based upon the "iss= ues going forward" as summarized in the IETF-84 minutes:

Note, that #12 and #13 can't be resolved until we h= ave a data model on the table. =A0However, we could start considering #14 &= amp; #15 (note that I've separated the decision about the signaling pro= tocol from the transport protocol). =A0This draft summarized various option= s for the "signaling protocol" (and not the transport protocol):= =A0
We didn't really make any progress on the topic really othe= r than agreeing that SDP is not sufficient for signaling CLUE information:<= /div>
http://www.ietf.org/proceedings/83/minutes/minutes-83-clue.txt

And, the call flow document we discussed at IETF-84 a= lso gets into the signaling solution:
<= br>
We are kind of in a chicken/egg situation right now since we = don't have a "message schema" or "clue instance" da= ta model developed. But, it might still be worthwhile to review the two abo= ve documents and at least eliminate some more of the options or agree some = things.

Regards,
Mary.=A0

--bcaec55240becbbf6104c846c01c-- From mary.ietf.barnes@gmail.com Mon Aug 27 15:35: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 31BEC21E803F for ; Mon, 27 Aug 2012 15:35:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.518 X-Spam-Level: X-Spam-Status: No, score=-103.518 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V8Wq1qa98OGo for ; Mon, 27 Aug 2012 15:35:05 -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 606C721E8034 for ; Mon, 27 Aug 2012 15:35:05 -0700 (PDT) Received: by lbky2 with SMTP id y2so2228691lbk.31 for ; Mon, 27 Aug 2012 15:35: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:cc:content-type; bh=6lFHOwU16HIpu9Nn5bAjjGMmtLKPKriXDLsQfTeDdxM=; b=av6Qg94Jgj5NrwJpq3M0OXN4LfyPlqPjhYGgCC1jfiTu+V42AXse2N/7dGBpuuRbtk wuIeHik/nVrcCo5uGDSi9aEsNPMLX5qmPOdH2RC9okf4xLiaJgXll822tXV4JN6GPJK0 5/01yie4Nw8z+BF3wl1rIABujtYK6vDggTWisxuiKb/AGF1M7acXiVhu8+fJ71JTvDNN kzfAkq04LavXT8GQvJLBAmdAI/juloKULBni0GGw2SfGsewFmgRThiJdZClvngQeIqD0 w5HqBIsWgLThEDtqnqMCxCTJIOaTw7df/GkckKQso/IJ+TlUoT58o7C4dKui07maMK7N RUhw== MIME-Version: 1.0 Received: by 10.152.104.44 with SMTP id gb12mr16439229lab.29.1346106904098; Mon, 27 Aug 2012 15:35:04 -0700 (PDT) Received: by 10.112.17.202 with HTTP; Mon, 27 Aug 2012 15:35:03 -0700 (PDT) Date: Mon, 27 Aug 2012 17:35:03 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=f46d04088ef5d935d704c846efe6 Subject: [clue] Tomorrow's design team 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: Mon, 27 Aug 2012 22:35:06 -0000 --f46d04088ef5d935d704c846efe6 Content-Type: text/plain; charset=ISO-8859-1 The meeting is on for tomorrow. We have lots that we could talk about. We can start going through these and see how far we get and continue discussion on the mailing list and then start back where we left off the following week (or revisit if we think we have some progress). 1) RTP requirements - per http://datatracker.ietf.org/doc/draft-lennox-clue-rtp-usage/ Does everyone agree these are sufficient and if not why and what's missing? 2) RTP topologies - per http://datatracker.ietf.org/doc/draft-even-clue-rtp-mapping/ Are these adequate and comprehensive? 3) Tele-medical use case - http://datatracker.ietf.org/doc/draft-ietf-clue-telepresence-use-cases/ Is this good - any other concerns? 4) Call flows in the framework document? Do we need them? 5) New signaling tickets - per the email I just posted (which isn't yet in the archives) Thanks, Mary. --f46d04088ef5d935d704c846efe6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The meeting is on for tomorrow. =A0We have lots that we could talk about. = =A0We can start going through these and see how far we get and continue dis= cussion on the mailing list and then start back where we left off the follo= wing week (or revisit if we think we have some progress).=A0

=A0 Does everyone agree these are suffic= ient and if not why and what's missing?=A0
=A0 Are these adequate and comprehensive?=A0
=A0 Is this good - an= y other concerns?=A0
4) Call flows in the framework document?
=A0 Do we need them= ?
5) New signaling tickets - per the email I just posted (which i= sn't yet in the archives)

Thanks,
Mary.
--f46d04088ef5d935d704c846efe6-- From spromano@unina.it Mon Aug 27 22:30: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 C865E21E8042 for ; Mon, 27 Aug 2012 22:30:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.806 X-Spam-Level: X-Spam-Status: No, score=-98.806 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, SARE_HTML_USL_OBFU=1.666, SARE_SUB_ENC_UTF8x2=0.246, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UhIP4E0k2yuG for ; Mon, 27 Aug 2012 22:30:11 -0700 (PDT) Received: from smtp1.unina.it (smtp1.unina.it [192.132.34.61]) by ietfa.amsl.com (Postfix) with ESMTP id 85CC721E803A for ; Mon, 27 Aug 2012 22:30:09 -0700 (PDT) Received: from 1-34-33-214.HINET-IP.hinet.net ([94.167.112.103]) (authenticated bits=0) by smtp1.unina.it (8.14.4/8.14.4) with ESMTP id q7S5U56I017156 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 28 Aug 2012 07:30:06 +0200 References: <806b5ee9-6e3d-40cf-bcb1-3dc1c44cde6a@email.android.com> User-Agent: K-9 Mail per Android In-Reply-To: <806b5ee9-6e3d-40cf-bcb1-3dc1c44cde6a@email.android.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----NFWKZPRENOZ84ESREPETZFPR6HHNFL" From: Simon Pietro Romano Date: Tue, 28 Aug 2012 07:30:03 +0200 To: Mary Barnes , CLUE Message-ID: <3f23835a-52da-4a41-9927-ab9cf1e033a6@email.android.com> Subject: Re: [clue] =?utf-8?q?FW=3A_New_Version_Notification_for=09draft-xiao-?= =?utf-8?q?clue-telemedical-use-case-00=2Etxt?= 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, 28 Aug 2012 05:30:12 -0000 ------NFWKZPRENOZ84ESREPETZFPR6HHNFL Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Hi Mary, I'll be glad to contribute to this work. Simon Mary Barnes ha scritto: No one has responded, so I will chime in. We will need a detailed call flow document that shows how the CLUE use cases are realized. It would be very useful to have one or two flows that show the SIP details as well as other protocols that might be involved. For XCON, we included a flow of how XCON interacts with the MEDIACTRL protocols in the detailed call flow document (RFC 6504). We only did this at the beginning and not for each and every call flow. Calls flows are terribly tedious, but they are extremely helpful when folks are trying to understand the protocol and they are an excellent way to sanity check things and find gaps, so I don't think we can get away with not doing them. I personally think it would add *alot* of value to have some high level call flows (similar to what Rob did for the tutorial) in the framework document. We did this for XCON for the majority of the use cases (per RFC 5239). Note, that we had textual descriptions of what happened at each stage. In CLUE, we have had snippets of these in the various presentations but I would love someone to step forward and do these. These then feed very naturally into the detailed call flow document that has all the protocol details. Mary. On Thu, Aug 9, 2012 at 4:10 PM, Paul Kyzivat wrote: On 8/8/12 6:09 PM, Christian Groves wrote: Hello Paul, I think those enhanced call flows are necessary. What do others think? Shall we ask that the call flows (at least some of them) include conference event package subscription and notifications and bfcp setup and signaling? I agree that this may be necessary - probably not in every call flow, but in cases where the use of those channels is necessary for the use case to work. And how often that is depends on how much information we defer to those protocols for. I think we need to understand how the XCON concepts will map to those we've created in CLUE. I agree an initial invite can establish a CLUE and BFCP stream and conference event package but there are dependencies between the data that will be sent across them, i.e. an end point will use some data from one protocol to send data in another, i.e. the media information in XCON would be dependent on what captures were agreed via CLUE. So whilst they can be established at the same time there is actually some sequencing needed. AFAIK currently in XCON there is no concept of captures, so no ability to describe them. So coming back to the example to the issue below. If we believe that for a description of the endpoint that XCON should be used rather than our CLUE description "Attribute" we should state this in the CLUE framework draft as an aid to interoperability (although I'm not sure how labelling in multiple languages would work?), do we use or or? Regards, Christian Thanks, Paul On 9/08/2012 12:12 AM, Paul Kyzivat wrote: On 8/7/12 10:44 PM, Christian Groves wrote: Hello Mary, I guess the reason why is the same reason why the media streams will likely be set up after CLUE. There could be potentially a large possible set of captures/configurations that you want to narrow down before you start assigning resources to them. You want to have enough information associated with the captures so that an educated decision can be made about whether to accept/use one. I don't think its enough just to assume that XCON will handle these things. I'm not sure I understand this. ISTM that the initial INVITE to set up a CLUE call could contain an offer of: - an initial audio and video stream - a CLUE protocol stream - a bfcp stream - indication of support for the conf event package As soon as the initial answer is sent, if not sooner, the CLUE stream and the bfcp stream can be opened, and a subscribe sent for the conf event package. Shortly thereafter, CLUE advertisements can be sent in both directions and a first notification for the conf event package can be sent. Then, both the advertisement and the conf event state can be used for constructing the CLUE configuration message. Maybe we should create an enhanced call flow that shows all of that. Thanks, Paul Regards, Christian On 2/08/2012 3:48 AM, Mary Barnes wrote: (As an individual) Why is it that you think XCON signaling with come after initial CLUE signaling? It is certainly possible to get an XCON notification before doing any CLUE signaling. CLUE will be reusing existing signaling protocols to establish the basic session - that would include using basic SIP conferencing and could include the use of XCON. Mary. On Mon, Jul 30, 2012 at 10:24 PM, Christian Groves > wrote: Hello Espen, The issue that I see is that the conference event package or XCON would come after the initial CLUE signalling. You may want to chose captures based on this high level information before XCON etc is established. However I think the main point is that we need to be a little more detailed when we describe the use of these fields if people are even now proposing different uses. Regards, Christian On 30/07/2012 11:46 PM, Espen Berger (espeberg) wrote: Hi Christian If a consumer want to learn about information that's on the level of " like "Teleconference Room 2, Beijing" I think its natural to look into conference event package or XCON. In the medical case the description attribute will have values like "x-ray" or "CT-scan", "Operation", which is needed since other captures attributes will have the same values. -Espen -----Original Message----- From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org ] On Behalf Of Christian Groves Sent: 27. juli 2012 06:42 To: clue@ietf.org Subject: Re: [clue] FW: New Version Notification for draft-xiao-clue-telemedical-use-case-00.txt Hello Paul, I think have a enumeration for very specific capabilities woul dbe hard but I think there may be some common ones to many conferencing / telepresence scenarios. In the discussion of this topic I think that perhaps the "description" attribute we have today may be too broad. I was thinking it would be used for something like "Teleconference Room 2, Beijing" but it seems there's proposals to use this for functional level things like "speaker etc". Regards, Christian On 26/07/2012 11:28 PM, Paul Kyzivat wrote: [as individual] On 7/26/12 2:51 AM, Xiaojing wrote: Hi Espen, Please see my response inline. Regards, Lennard -----Original Message----- From: Espen Berger (espeberg) [mailto:espeberg@cisco.com ] Sent: Wednesday, July 25, 2012 11:19 PM To: Xiaojing; clue@ietf.org Subject: RE: [clue] FW: New Version Notification for draft-xiao-clue-telemedical-use-case-00.txt Thanks for sharing the use case. I had a similar use case in mind, advanced lecture type calls mainly focusing on P2P with multiple presentation streams. My assumption for an advanced use case like this is each capture has at least a description field, e.g. 'x-ray' or 'CT-scan', that can be used by a manual operator to start and stop what to receive. This use case explains why we need descriptions for both capture-scenes and captures. [Xiao Jing] I share the same thinking on the description field with you. The different presentations need to be identified from each other. A straightforward way is to add description tags to them. I think a textual description is the place to start. It would be hard to start defining a machine-processable enumeration of application-specific categories. We already have the proposal for such a mechanism. This use case simply reinforces the need for that mechanism. Questions * Do you assume manual or automatic selection of presentation streams? [Xiao Jing] In my initial thinking, in the use case it is the surgeon and endpoint users who decide which presentation streams to be sent and displayed. Thus it is necessary to identify the presentations. * How do you decide which presentation streams are important? What if you offer three presentation streams and I can only receive one, how do I decide which of them to receive? [Xiao Jing] I assume that the users can differentiate the streams and then decide which to receive. In this case, if the user knows exactly what the stream is about, he can decide without additional information from the provider. But I also think we can introduced kind of priority concept into it. The "content" attribute could be a good place to include this idea. In my memory, Christian and Paul are working on this issue, and I'll try to inform them to take this into consideration. * Have you identified additional meta-information to the CLUE framework needed to describe the information you have in mind writing up the use case. [Xiao Jing] In this early stage, I'm just trying to draw concern about the necessity of having multiple presentation streams. I think the current framework can cover all the new requirements coming up with this use case at ease. I'm not sure whether 'priority' has been brought up on this public list or not. But it is my thought that we need a numeric priority value per capture, that can be used by the recipient when it doesn't have the resources to render even the smallest entry from each scene. *That* would provide a way for the receiving equipment to provide a default rendering. Some endpoints might also provide a gui for the end users to manually configure based on descriptions. The numeric priority could be used to indicate that the presentation is more important than the speaker, or visa versa. And it can be used to indicate a relative priority among presentations. Etc. Thanks, Paul Regards -Espen -----Original Message----- From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org ] On Behalf Of Xiaojing Sent: 25. juli 2012 04:40 To: clue@ietf.org Subject: [clue] FW: New Version Notification for draft-xiao-clue-telemedical-use-case-00.txt Hi all, I've submitted a telemedical use case, which addresses the use of Telepresence into medical scenarios. I think this use case is valid to add another application field where Telepresence can be used. So I'd like to suggest adding this use case into the current use case document. Also, along with this use case, some new requirements might come up, e.g. the requirement to support multiple presentation streams, which might be considered into the requirement draft. Best regards, Lennard -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org ] Sent: Monday, July 09, 2012 11:13 AM To: Xiaojing Cc: Roni even Subject: New Version Notification for draft-xiao-clue-telemedical-use-case-00.txt A new version of I-D, draft-xiao-clue-telemedical-use-case-00.txt has been successfully submitted by Lennard Xiao and posted to the IETF repository. Filename: draft-xiao-clue-telemedical-use-case Revision: 00 Title: Use Case for Telemedical with Multi-streams Creation date: 2012-07-06 WG ID: Individual Submission Number of pages: 5 URL: http://www.ietf.org/internet-drafts/draft-xiao-clue-telemedical-use-c ase-00.txt Status: http://datatracker.ietf.org/doc/draft-xiao-clue-telemedical-use-case Htmlized: http://tools.ietf.org/html/draft-xiao-clue-telemedical-use-case-00 Abstract: This memo presenst a telemedicine use case where multiple presentation streams are used for conveying different information in parallel to the main video from the surgery room 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 _______________________________________________ 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 ------NFWKZPRENOZ84ESREPETZFPR6HHNFL Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Hi Mary,

I'll be glad to contribute to this work.
Simon

Mary Barnes <mary.ietf.barnes@gmail.com> ha scritto:
No one has responded, so I will chime in.  We will need a detailed call flow document that shows how the CLUE use cases are realized.  It would be very useful to have one or two flows that show the SIP details as well as other protocols that might be involved.  For XCON, we included a flow of how XCON interacts with the MEDIACTRL protocols in the detailed call flow document (RFC 6504).  We only did this at the beginning and not for each and every call flow. 

Calls flows are terribly tedious, but they are extremely helpful when folks are trying to understand the protocol and they are an excellent way to sanity check things and find gaps, so I don't think we can get away with not doing them.   I personally think it would add *alot* of value to have some high level call flows (similar to what Rob did for the tutorial) in the framework document.  We did this for XCON for the majority of the use cases (per RFC 5239).  Note, that we had textual descriptions of what happened at each stage. In CLUE, we have had snippets of these in the various presentations but I would love someone to step forward and do these.  These then feed very naturally into the detailed call flow document that has all the protocol details.   

Mary. 

On Thu, Aug 9, 2012 at 4:10 PM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
On 8/8/12 6:09 PM, Christian Groves wrote:
Hello Paul,

I think those enhanced call flows are necessary.

What do others think? Shall we ask that the call flows (at least some of them) include conference event package subscription and notifications and bfcp setup and signaling?

I agree that this may be necessary - probably not in every call flow, but in cases where the use of those channels is necessary for the use case to work. And how often that is depends on how much information we defer to those protocols for.


I think we need to
understand how the XCON concepts will map to those we've created in
CLUE. I agree an initial invite can establish a CLUE and BFCP stream and
conference event package but there are dependencies between the data
that will be sent across them, i.e. an end point will use some data from
one protocol to send data in another, i.e. the media information in XCON
would be dependent on what captures were agreed via CLUE. So whilst they
can be established at the same time there is actually some sequencing
needed. AFAIK currently in XCON there is no concept of captures, so no
ability to describe them.

So coming back to the example to the issue below. If we believe that for
a description of the endpoint that XCON should be used rather than our
CLUE description "Attribute" we should state this in the CLUE framework
draft as an aid to interoperability (although I'm not sure how labelling
in multiple languages would work?), do we use <users><display-text> or
<conference-description><display-text> or?

Regards, Christian

        Thanks,
        Paul


On 9/08/2012 12:12 AM, Paul Kyzivat wrote:
On 8/7/12 10:44 PM, Christian Groves wrote:
Hello Mary,

I guess the reason why is the same reason why the media streams will
likely be set up after CLUE. There could be potentially a large possible
set of captures/configurations that you want to narrow down before you
start assigning resources to them. You want to have enough information
associated with the captures so that an educated decision can be made
about whether to accept/use one. I don't think its enough just to assume
that XCON will handle these things.

I'm not sure I understand this.

ISTM that the initial INVITE to set up a CLUE call could contain an
offer of:
- an initial audio and video stream
- a CLUE protocol stream
- a bfcp stream
- indication of support for the conf event package

As soon as the initial answer is sent, if not sooner, the CLUE stream
and the bfcp stream can be opened, and a subscribe sent for the conf
event package. Shortly thereafter, CLUE advertisements can be sent in
both directions and a first notification for the conf event package
can be sent.

Then, both the advertisement and the conf event state can be used for
constructing the CLUE configuration message.

Maybe we should create an enhanced call flow that shows all of that.

Thanks,
Paul

Regards, Christian

On 2/08/2012 3:48 AM, Mary Barnes wrote:
(As an individual)

Why is it that you think XCON signaling with come after initial CLUE
signaling? It is certainly possible to get an XCON notification before
doing any CLUE signaling. CLUE will be reusing existing signaling
protocols to establish the basic session - that would include using
basic SIP conferencing and could include the use of XCON.

Mary.

On Mon, Jul 30, 2012 at 10:24 PM, Christian Groves
<Christian.Groves@nteczone.com <mailto:Christian.Groves@nteczone.com>>
wrote:

Hello Espen,

The issue that I see is that the conference event package or XCON
would come after the initial CLUE signalling. You may want to
chose captures based on this high level information before XCON
etc is established. However I think the main point is that we need
to be a little more detailed when we describe the use of these
fields if people are even now proposing different uses.

Regards, Christian


On 30/07/2012 11:46 PM, Espen Berger (espeberg) wrote:

Hi Christian

If a consumer want to learn about information that's on the
level of " like "Teleconference Room 2, Beijing" I think its
natural to look into conference event package or XCON.

In the medical case the description attribute will have values
like "x-ray" or "CT-scan", "Operation", which is needed since
other captures attributes will have the same values.

-Espen


-----Original Message-----
From: clue-bounces@ietf.org <mailto:clue-bounces@ietf.org>
[mailto:clue-bounces@ietf.org <mailto:clue-bounces@ietf.org>]
On Behalf Of Christian Groves
Sent: 27. juli 2012 06:42
To: clue@ietf.org <mailto:clue@ietf.org>
Subject: Re: [clue] FW: New Version Notification for
draft-xiao-clue-telemedical-use-case-00.txt

Hello Paul,

I think have a enumeration for very specific capabilities woul
dbe hard but I think there may be some common ones to many
conferencing / telepresence scenarios. In the discussion of
this topic I think that perhaps the "description" attribute we
have today may be too broad. I was thinking it would be used
for something like "Teleconference Room 2, Beijing" but it
seems there's proposals to use this for functional level
things like "speaker etc".

Regards, Christian

On 26/07/2012 11:28 PM, Paul Kyzivat wrote:

[as individual]

On 7/26/12 2:51 AM, Xiaojing wrote:

Hi Espen,

Please see my response inline.

Regards,
Lennard

-----Original Message-----
From: Espen Berger (espeberg)
[mailto:espeberg@cisco.com <mailto:espeberg@cisco.com>]
Sent: Wednesday, July 25, 2012 11:19 PM
To: Xiaojing; clue@ietf.org <mailto:clue@ietf.org>
Subject: RE: [clue] FW: New Version Notification for
draft-xiao-clue-telemedical-use-case-00.txt

Thanks for sharing the use case. I had a similar use
case in mind,
advanced lecture type calls mainly focusing on P2P
with multiple
presentation streams.

My assumption for an advanced use case like this is
each capture has
at least a description field, e.g. 'x-ray' or
'CT-scan', that can be
used by a manual operator to start and stop what to
receive. This use
case explains why we need descriptions for both
capture-scenes and
captures.

[Xiao Jing] I share the same thinking on the
description field with
you. The different presentations need to be identified
from each
other. A straightforward way is to add description
tags to them.

I think a textual description is the place to start.
It would be hard to start defining a machine-processable
enumeration
of application-specific categories.

We already have the proposal for such a mechanism.
This use case simply reinforces the need for that mechanism.

Questions
* Do you assume manual or automatic selection of
presentation streams?
[Xiao Jing] In my initial thinking, in the use case it
is the surgeon
and endpoint users who decide which presentation
streams to be sent
and displayed. Thus it is necessary to identify the
presentations.
* How do you decide which presentation streams are
important? What if
you offer three presentation streams and I can only
receive one, how
do I decide which of them to receive?
[Xiao Jing] I assume that the users can differentiate
the streams and
then decide which to receive. In this case, if the
user knows exactly
what the stream is about, he can decide without additional
information from the provider. But I also think we can
introduced
kind of priority concept into it. The "content"
attribute could be a
good place to include this idea. In my memory,
Christian and Paul are
working on this issue, and I'll try to inform them to
take this into
consideration.
* Have you identified additional meta-information to
the CLUE
framework needed to describe the information you have
in mind writing
up the use case.
[Xiao Jing] In this early stage, I'm just trying to
draw concern
about the necessity of having multiple presentation
streams. I think
the current framework can cover all the new
requirements coming up
with this use case at ease.

I'm not sure whether 'priority' has been brought up on
this public
list or not.

But it is my thought that we need a numeric priority value per
capture, that can be used by the recipient when it doesn't
have the
resources to render even the smallest entry from each
scene. *That*
would provide a way for the receiving equipment to provide
a default
rendering. Some endpoints might also provide a gui for the
end users
to manually configure based on descriptions.

The numeric priority could be used to indicate that the
presentation
is more important than the speaker, or visa versa. And it
can be used
to indicate a relative priority among presentations. Etc.

Thanks,
Paul

Regards

-Espen


-----Original Message-----
From: clue-bounces@ietf.org
<mailto:clue-bounces@ietf.org>
[mailto:clue-bounces@ietf.org
<mailto:clue-bounces@ietf.org>] On Behalf
Of Xiaojing
Sent: 25. juli 2012 04:40
To: clue@ietf.org <mailto:clue@ietf.org>
Subject: [clue] FW: New Version Notification for
draft-xiao-clue-telemedical-use-case-00.txt

Hi all,

I've submitted a telemedical use case, which addresses
the use of
Telepresence into medical scenarios.

I think this use case is valid to add another
application field where
Telepresence can be used.
So I'd like to suggest adding this use case into the
current use case
document.

Also, along with this use case, some new requirements
might come up,
e.g. the requirement to support multiple presentation
streams, which
might be considered into the requirement draft.

Best regards,
Lennard

-----Original Message-----
From: internet-drafts@ietf.org
<mailto:internet-drafts@ietf.org>
[mailto:internet-drafts@ietf.org
<mailto:internet-drafts@ietf.org>]
Sent: Monday, July 09, 2012 11:13 AM
To: Xiaojing
Cc: Roni even
Subject: New Version Notification for
draft-xiao-clue-telemedical-use-case-00.txt


A new version of I-D,
draft-xiao-clue-telemedical-use-case-00.txt
has been successfully submitted by Lennard Xiao and
posted to the
IETF repository.

Filename: draft-xiao-clue-telemedical-use-case
Revision: 00
Title: Use Case for Telemedical with Multi-streams
Creation date: 2012-07-06
WG ID: Individual Submission
Number of pages: 5
URL:
http://www.ietf.org/internet-drafts/draft-xiao-clue-telemedical-use-c
ase-00.txt
Status:
http://datatracker.ietf.org/doc/draft-xiao-clue-telemedical-use-case
Htmlized:
http://tools.ietf.org/html/draft-xiao-clue-telemedical-use-case-00


Abstract:
This memo presenst a telemedicine use case where
multiple
presentation streams are used for conveying
different information in
parallel to the main video from the surgery room




The IETF Secretariat
_______________________________________________
clue mailing list
clue@ietf.org <mailto:clue@ietf.org>
https://www.ietf.org/mailman/listinfo/clue
_______________________________________________
clue mailing list
clue@ietf.org <mailto:clue@ietf.org>
https://www.ietf.org/mailman/listinfo/clue

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

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


_______________________________________________
clue mailing list
clue@ietf.org <mailto: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

------NFWKZPRENOZ84ESREPETZFPR6HHNFL-- From christer.holmberg@ericsson.com Tue Aug 28 00:17: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 39CDE11E808D for ; Tue, 28 Aug 2012 00:17:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.158 X-Spam-Level: X-Spam-Status: No, score=-6.158 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uERgSG3nMeLS for ; Tue, 28 Aug 2012 00:17:42 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 3F95F21F8444 for ; Tue, 28 Aug 2012 00:17:41 -0700 (PDT) X-AuditID: c1b4fb25-b7f046d00000644c-d8-503c709386a7 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 85.00.25676.3907C305; Tue, 28 Aug 2012 09:17:40 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.99]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Tue, 28 Aug 2012 09:17:39 +0200 From: Christer Holmberg To: clue issue tracker , "clue-chairs@tools.ietf.org" , "mary.ietf.barnes@gmail.com" Date: Tue, 28 Aug 2012 09:17:38 +0200 Thread-Topic: [clue] #14: How do we transport the CLUE information? Thread-Index: Ac2En7YMgdQkf/lOQdWis7A0iVzFAQATMYhg Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585340A356C46@ESESSCMS0356.eemea.ericsson.se> References: <068.890588ccdb9d1a0b74f5999dd9ddcd35@trac.tools.ietf.org> In-Reply-To: <068.890588ccdb9d1a0b74f5999dd9ddcd35@trac.tools.ietf.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrFLMWRmVeSWpSXmKPExsUyM+Jvre6UApsAg87r3BYzp31gtdh/6jKz xef9+5ktHj3pYHJg8dg56y67x5IlP5k8vlz+zObxc89m1gCWKC6blNSczLLUIn27BK6M/r43 jAUPBCpuHr7O2MC4QqCLkZNDQsBEYv7cl6wQtpjEhXvr2UBsIYFTjBLXJlZ1MXIB2QsYJe5s +szUxcjBwSZgIdH9TxskLiKwgVHi9MPdzCANzALKEl8bNjGB2CwCqhLtN9YwgtjCAs4S51ua wWpEBFwk+h5fY4GwjSS2XO0Hq+cVCJdYO+c2E8RiN4lVUw+D9XIKuEssmLsVrJcR6Ljvp9Yw QewSl7j1ZD4TxNECEkv2nGeGsEUlXj7+xwpRLypxp309I8jNzAKaEut36UO0KkpM6X7IDrFW UOLkzCcsExjFZiGZOguhYxaSjllIOhYwsqxiFM5NzMxJLzfSSy3KTC4uzs/TK07dxAiMr4Nb fqvuYLxzTuQQozQHi5I4r/XWPf5CAumJJanZqakFqUXxRaU5qcWHGJk4OKUaGCXa0+v2714c ECO3x9t3f9085WVlGoz6gjdtn2R/yn4vfO6W+8OgoD+Mcl7iG/ce5k+LnNepeXSfvH2H4M2J GWKiMbtuLz46v5e3Z37Woa55b5acE3Bd8WarT/izObdEFhTy1VR7ph86t3mrjsUhA7aZV+vt Cw6s8VRpk3zJr7Qvn1lft9NOQ4mlOCPRUIu5qDgRAPbVZdp9AgAA Cc: "clue@ietf.org" Subject: Re: [clue] #14: How do we transport the CLUE information? 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, 28 Aug 2012 07:17:43 -0000 SGksDQoNCkEgcXVlc3Rpb24gZm9yIGNsYXJpZmljYXRpb246IGRvIHdlIGFzc3VtZSB0aGVyZSB3 aWxsIGJlIE9ORSB0cmFuc3BvcnQgcHJvdG9jb2wsIG9yIGNvdWxkIHRoZXJlIHBvc3NpYmx5IGJl IG1hbnk/DQoNCkkgZ3Vlc3MgaXQgZGVwZW5kcyBvbiB3aGF0IHdlIHJlYWxseSBtZWFuIGJ5ICJD TFVFIGluZm9ybWF0aW9uIi4gQnV0LCB0aGVyZSBjb3VsZCBlLmcuIGJlIHNvbWUgaW5mb3JtYXRp b24sIG5lZWRlZCBmb3IgQ0xVRSwgdGhhdCB3ZSBpbnNlcnQgaW4gU0RQICh0aGVyZSBpcyBldmVu IGEgdGlja2V0IGZvciB0aGF0KSwgd2hpbGUgb3RoZXIgaW5mb3JtYXRpb24gaXMgdHJhbnNwb3J0 ZWQgdXNpbmcgc29tZSBvdGhlciBtZWNoYW5pc20uDQoNCkFsc28sIHdlIGhhdmUgYmVlbiB0YWxr aW5nIGFib3V0IHRyYW5zcG9ydGluZyB0aGUgY29udGVudC1pZCB1c2luZyBzb21lIFJUUCBleHRl bnNpb24uDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQpGcm9tOiBjbHVlLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpjbHVlLWJvdW5jZXNAaWV0 Zi5vcmddIE9uIEJlaGFsZiBPZiBjbHVlIGlzc3VlIHRyYWNrZXINClNlbnQ6IDI4LiBlbG9rdXV0 YSAyMDEyIDE6MDMNClRvOiBjbHVlLWNoYWlyc0B0b29scy5pZXRmLm9yZzsgbWFyeS5pZXRmLmJh cm5lc0BnbWFpbC5jb20NCkNjOiBjbHVlQGlldGYub3JnDQpTdWJqZWN0OiBbY2x1ZV0gIzE0OiBI b3cgZG8gd2UgdHJhbnNwb3J0IHRoZSBDTFVFIGluZm9ybWF0aW9uPw0KDQojMTQ6IEhvdyBkbyB3 ZSB0cmFuc3BvcnQgdGhlIENMVUUgaW5mb3JtYXRpb24/DQoNCiBXaGF0IHRyYW5zcG9ydCBwcm90 b2NvbCBzaG91bGQgYmUgdXNlZCBmb3IgdGhlIENMVUUgc3BlY2lmaWMgc2lnbmFsaW5nICBpbmZv cm1hdGlvbj8NCg0KLS0gDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NCiBSZXBvcnRlcjogIG1hcnkuaWV0Zi5iYXJuZXNA4oCmICB8 ICAgICAgT3duZXI6ICBjbHVlLWNoYWlyc0DigKYNCiAgICAgVHlwZTogIHRhc2sgICAgICAgICAg ICAgICAgfCAgICAgU3RhdHVzOiAgbmV3DQogUHJpb3JpdHk6ICBibG9ja2VyICAgICAgICAgICAg IHwgIE1pbGVzdG9uZTogIG1pbGVzdG9uZTENCkNvbXBvbmVudDogIGNoYXJ0ZXIgICAgICAgICAg ICAgfCAgICBWZXJzaW9uOiAgMS4wDQogU2V2ZXJpdHk6ICAtICAgICAgICAgICAgICAgICAgIHwg ICBLZXl3b3JkczoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KDQpUaWNrZXQgVVJMOiA8aHR0cDovL3RyYWMudG9vbHMuaWV0Zi5v cmcvd2cvY2x1ZS90cmFjL3RpY2tldC8xND4NCmNsdWUgPGh0dHA6Ly90b29scy5pZXRmLm9yZy93 Zy9jbHVlLz4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCmNsdWUgbWFpbGluZyBsaXN0DQpjbHVlQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2NsdWUNCg== From christer.holmberg@ericsson.com Tue Aug 28 00:21: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 C09F111E80D1 for ; Tue, 28 Aug 2012 00:21:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.159 X-Spam-Level: X-Spam-Status: No, score=-6.159 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pPw46VF-3+hs for ; Tue, 28 Aug 2012 00:21:54 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id BCD8F11E80D3 for ; Tue, 28 Aug 2012 00:21:53 -0700 (PDT) X-AuditID: c1b4fb25-b7f046d00000644c-7b-503c718f0e43 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 47.B0.25676.F817C305; Tue, 28 Aug 2012 09:21:51 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.99]) by esessmw0256.eemea.ericsson.se ([153.88.115.96]) with mapi; Tue, 28 Aug 2012 09:21:51 +0200 From: Christer Holmberg To: "clue-chairs@tools.ietf.org" , "mary.ietf.barnes@gmail.com" Date: Tue, 28 Aug 2012 09:21:50 +0200 Thread-Topic: [clue] #14: How do we transport the CLUE information? Thread-Index: Ac2En7YMgdQkf/lOQdWis7A0iVzFAQATMYhgAABO4TA= Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585340A356C4F@ESESSCMS0356.eemea.ericsson.se> References: <068.890588ccdb9d1a0b74f5999dd9ddcd35@trac.tools.ietf.org> <7F2072F1E0DE894DA4B517B93C6A0585340A356C46@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585340A356C46@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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrPLMWRmVeSWpSXmKPExsUyM+JvrW5/oU2AQcsaQ4uZ0z6wWuw/dZnZ 4vP+/cwOzB47Z91l91iy5CeTx5fLn9kCmKO4bFJSczLLUov07RK4Mtb3+Rb0iVWcuPWfrYHx iGgXIyeHhICJxL83X9ghbDGJC/fWs3UxcnEICZxilPh+uZEdwlnAKHHpyz6WLkYODjYBC4nu f9ogDSICVRI7Wx6xgtjMAsoSXxs2MYHYLAKqEk2n1rGB2MICThLXX35jhKh3lri8+AcbhG0l seXHSxYQm1cgXGLf1ztgvUICUxgl7nfwgNicAhESu+4tAKthBDru+6k1TBC7xCVuPZnPBHG0 gMSSPeeZIWxRiZeP/7FC1ItK3GlfzwhyMrOApsT6XfoQrYoSU7ofskOsFZQ4OfMJywRGsVlI ps5C6JiFpGMWko4FjCyrGIVzEzNz0suN9FKLMpOLi/Pz9IpTNzECI+nglt+qOxjvnBM5xCjN waIkzmu9dY+/kEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBkab2x9Mg1YLf1i74LE89zuxuClF Cx78nLXEXO3LDRcbHf2jZTvtPwewGYcWfH5xR9vWJulTgf6BdakHnUqCBZJNn8WtK2l9t0A+ aZ3pF1VJkf/SKhLfTL7pNGX8+FOvfrJEIWmvf8BWs5iLC61sbycf/lF32f2c6ol7WTy7T04M iV4Up6DjVqLEUpyRaKjFXFScCACoLb+JcgIAAA== Cc: "clue@ietf.org" Subject: Re: [clue] #14: How do we transport the CLUE information? 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, 28 Aug 2012 07:21:55 -0000 Q29ycmVjdGlvbjogY29udGVudC1pZCBzaGFsbCBvZiBjb3Vyc2UgYmUgY2FwdHVyZS1pZC4NCg0K LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGNsdWUtYm91bmNlc0BpZXRmLm9yZyBb bWFpbHRvOmNsdWUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIENocmlzdGVyIEhvbG1i ZXJnDQpTZW50OiAyOC4gZWxva3V1dGEgMjAxMiAxMDoxOA0KVG86IGNsdWUgaXNzdWUgdHJhY2tl cjsgY2x1ZS1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc7IG1hcnkuaWV0Zi5iYXJuZXNAZ21haWwuY29t DQpDYzogY2x1ZUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtjbHVlXSAjMTQ6IEhvdyBkbyB3ZSB0 cmFuc3BvcnQgdGhlIENMVUUgaW5mb3JtYXRpb24/DQoNCkhpLA0KDQpBIHF1ZXN0aW9uIGZvciBj bGFyaWZpY2F0aW9uOiBkbyB3ZSBhc3N1bWUgdGhlcmUgd2lsbCBiZSBPTkUgdHJhbnNwb3J0IHBy b3RvY29sLCBvciBjb3VsZCB0aGVyZSBwb3NzaWJseSBiZSBtYW55Pw0KDQpJIGd1ZXNzIGl0IGRl cGVuZHMgb24gd2hhdCB3ZSByZWFsbHkgbWVhbiBieSAiQ0xVRSBpbmZvcm1hdGlvbiIuIEJ1dCwg dGhlcmUgY291bGQgZS5nLiBiZSBzb21lIGluZm9ybWF0aW9uLCBuZWVkZWQgZm9yIENMVUUsIHRo YXQgd2UgaW5zZXJ0IGluIFNEUCAodGhlcmUgaXMgZXZlbiBhIHRpY2tldCBmb3IgdGhhdCksIHdo aWxlIG90aGVyIGluZm9ybWF0aW9uIGlzIHRyYW5zcG9ydGVkIHVzaW5nIHNvbWUgb3RoZXIgbWVj aGFuaXNtLg0KDQpBbHNvLCB3ZSBoYXZlIGJlZW4gdGFsa2luZyBhYm91dCB0cmFuc3BvcnRpbmcg dGhlIGNvbnRlbnQtaWQgdXNpbmcgc29tZSBSVFAgZXh0ZW5zaW9uLg0KDQpSZWdhcmRzLA0KDQpD aHJpc3Rlcg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogY2x1ZS1ib3VuY2Vz QGlldGYub3JnIFttYWlsdG86Y2x1ZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgY2x1 ZSBpc3N1ZSB0cmFja2VyDQpTZW50OiAyOC4gZWxva3V1dGEgMjAxMiAxOjAzDQpUbzogY2x1ZS1j aGFpcnNAdG9vbHMuaWV0Zi5vcmc7IG1hcnkuaWV0Zi5iYXJuZXNAZ21haWwuY29tDQpDYzogY2x1 ZUBpZXRmLm9yZw0KU3ViamVjdDogW2NsdWVdICMxNDogSG93IGRvIHdlIHRyYW5zcG9ydCB0aGUg Q0xVRSBpbmZvcm1hdGlvbj8NCg0KIzE0OiBIb3cgZG8gd2UgdHJhbnNwb3J0IHRoZSBDTFVFIGlu Zm9ybWF0aW9uPw0KDQogV2hhdCB0cmFuc3BvcnQgcHJvdG9jb2wgc2hvdWxkIGJlIHVzZWQgZm9y IHRoZSBDTFVFIHNwZWNpZmljIHNpZ25hbGluZyAgaW5mb3JtYXRpb24/DQoNCi0tIA0KLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQog UmVwb3J0ZXI6ICBtYXJ5LmlldGYuYmFybmVzQOKApiAgfCAgICAgIE93bmVyOiAgY2x1ZS1jaGFp cnNA4oCmDQogICAgIFR5cGU6ICB0YXNrICAgICAgICAgICAgICAgIHwgICAgIFN0YXR1czogIG5l dw0KIFByaW9yaXR5OiAgYmxvY2tlciAgICAgICAgICAgICB8ICBNaWxlc3RvbmU6ICBtaWxlc3Rv bmUxDQpDb21wb25lbnQ6ICBjaGFydGVyICAgICAgICAgICAgIHwgICAgVmVyc2lvbjogIDEuMA0K IFNldmVyaXR5OiAgLSAgICAgICAgICAgICAgICAgICB8ICAgS2V5d29yZHM6DQotLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KVGlj a2V0IFVSTDogPGh0dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL3dnL2NsdWUvdHJhYy90aWNrZXQv MTQ+DQpjbHVlIDxodHRwOi8vdG9vbHMuaWV0Zi5vcmcvd2cvY2x1ZS8+DQoNCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpjbHVlIG1haWxpbmcgbGlzdA0K Y2x1ZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jbHVl DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KY2x1ZSBt YWlsaW5nIGxpc3QNCmNsdWVAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vY2x1ZQ0K From ron.even.tlv@gmail.com Tue Aug 28 02:58: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 A1CFE21F8554 for ; Tue, 28 Aug 2012 02:58:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b-fEK4kW67Xw for ; Tue, 28 Aug 2012 02:58:30 -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 2FF0E21F8557 for ; Tue, 28 Aug 2012 02:58:30 -0700 (PDT) Received: by bkty12 with SMTP id y12so1259642bkt.31 for ; Tue, 28 Aug 2012 02:58:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:message-id:mime-version:content-type:x-mailer :thread-index:content-language; bh=KQByQFbJ8/G9lMgcR51cuRIHnXj7ff0NR/SU7Y5DpR4=; b=aT3k22xaxTm5bQkO2p3fgtReoKKSI6YcVDa9eCauwdrJwroMk589VuFAo6Yck2tI9p zY2o9+OaaXrr26WrXyPKO7Cmu59m6R/U4DFqKAUcUZ2twLQlv5oUPwDo9QMYQIvikg7d pcnD92tT/RWT9ZgTDmlY5gr7dpjKKeJPsWevdJoCVl22Qd1aii/9s9+FRhDzGStu29RL nob+BKjQJiu53E4fkBLxP6xEITAlqelAckzgnD1kbWQFFf6jzAnN1ghRxOz73DIVHYpn kbwBYxJIfyuqaY5IrlydPipfMXar0DiLaYxMqEkB5v5HlL/+iLV+gVLzhGr5ACgjUYpH VtDg== Received: by 10.204.157.18 with SMTP id z18mr4783389bkw.16.1346147901796; Tue, 28 Aug 2012 02:58:21 -0700 (PDT) Received: from RoniE ([109.67.233.208]) by mx.google.com with ESMTPS id n5sm12240225bkv.14.2012.08.28.02.58.19 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 28 Aug 2012 02:58:20 -0700 (PDT) From: "Roni Even" To: Date: Tue, 28 Aug 2012 12:57:02 +0200 Message-ID: <011a01cd850b$dcbcaf20$96360d60$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_011B_01CD851C.A0469090" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac2FC0lzIVXO3mZsTXOIfw7zFr9yHQ== Content-Language: en-us Subject: [clue] The requirements in draft-lennox-clue-rtp-usage-04 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, 28 Aug 2012 09:58:32 -0000 This is a multipart message in MIME format. ------=_NextPart_000_011B_01CD851C.A0469090 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I have some comments on the requirements in section 9 of draft-lennox-clue-rtp-usage-04. 1. The first requirement should be that any solution must work with existing protocols and should not require duplication of information sent using existing protocol. 2. I am not sure if media-4 and media-5 are requirements or description of the flow. 3. In media-6 the term "immediately" is vague, I assume that the mapping should be available before a new source is received. I think this is nice to have but we do not have a requirement for reliable delivery, maybe one should be added or is this a requirement for reliable delivery. 4. In media-6 the sentence "and thus that any previous source is no longer being mapped to that switched capture." is not clear and I am not sure if it is true, I think it can be deleted since it does not provide value. 5. In Media-8 the sentence "It must be possible for a source to move among switched captures without requiring a refresh of decoder state (e.g., for video, a fresh I-frame), when this is unnecessary." I think that instead of saying "when this is unnecessary" is should say "if the receiver support this funcationality". 6. In Media -8 the sentence "However, it must also be possible for a receiver to indicate when a refresh of decoder state is in fact necessary". Is this a CLUE or RTP mapping requirement? Should CLUE provide means for it, otherwise I do not see any point in having this sentence since this is current practice for switching and there is no intention to change it. 7. In Media-9 the sentence "it should be possible for a sender to send only one copy of the source". This is true only if the receiver supports it so suggest adding to the end of the sentence "if the receiver supports it". Note that this requirement and requirement 8 require new capability negotiation. 8. In media 10 "media flows should, as much as possible, look and behave like currently-defined usages of existing protocols". Is this a suggestion to change RTP? If not what is this requirement about the media flow? 9. I do not think that Media- 11 is correct. The processing depends on the topology chosen by the implementer. So if you want such requirement it should say per topology "to have lower burden per topology". The selection of topologies has to do with application decision like source hiding, central decision preferences. 10. I do not think that requirement 12 is adding something new which is not part of RTP/RTCP or is there some new information needed? BTW: the requirements are discussed in section 5 of draft-even-clue-rtp-mapping-03 Roni Even ------=_NextPart_000_011B_01CD851C.A0469090 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I have = some comments on the requirements in section 9 of = draft-lennox-clue-rtp-usage-04.

 

1.       = The first requirement = should be that any solution must work with existing protocols and should = not require duplication of information sent using existing = protocol.

2.       = I am not sure if media-4 = and media-5 are requirements or description of the = flow.

3.       = In media-6 the term = “immediately” is vague,  I assume that the mapping = should be available before a new source is received. I think this is = nice to have but we do not have a requirement for reliable delivery, = maybe one should be added or is this a requirement for reliable = delivery.

4.       = In media-6 the sentence = “and thus that any previous source is no longer being mapped to = that switched capture.” is not clear and I am not sure if it is = true, I think it can be deleted since it does not provide = value.

5.       = In Media-8 the sentence = “It must be possible for a source to move among switched captures = without requiring a refresh of decoder state (e.g., for video, a fresh = I-frame), when this is unnecessary.” I think that instead of = saying “when this is unnecessary” is should say “if = the receiver support this funcationality”.

6.       = In Media -8 the sentence = “However, it must also be possible for a receiver to indicate when = a refresh of decoder state is in fact necessary”.  Is this a = CLUE or RTP mapping requirement? Should CLUE provide means for it, = otherwise I do not see any point in having this sentence since this is = current practice for switching and there is no intention to change = it.

7.       = In Media-9 the sentence = “it should be  possible for a sender to send only one copy of = the source”. This is true only if the receiver supports it so = suggest adding to the end of the sentence “if the receiver = supports it”. Note that this requirement and requirement 8 require = new capability negotiation.

8.       = In media 10 “media = flows should, as much as possible, look and behave like = currently-defined usages of existing protocols”. Is this a = suggestion to change RTP? If not what is this requirement about the = media flow?

9.       = I do not think that = Media- 11 is correct. The processing depends on the topology chosen by = the implementer. So if you want such requirement it should say per = topology “to have lower burden per topology”. The selection = of topologies has to do with application decision like source hiding, = central decision preferences.

10.   I do = not think that requirement 12 is adding something new which is not part = of RTP/RTCP or is there some new information needed?

 

BTW: the = requirements are discussed in section 5 of  draft-even-clue-rtp-mapping-03

 

Roni Even

 

------=_NextPart_000_011B_01CD851C.A0469090-- From ron.even.tlv@gmail.com Tue Aug 28 02:59: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 D742521F8552 for ; Tue, 28 Aug 2012 02:59:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xQBOsiIBQiCi for ; Tue, 28 Aug 2012 02:59:56 -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 D32E521F853F for ; Tue, 28 Aug 2012 02:59:55 -0700 (PDT) Received: by bkty12 with SMTP id y12so1260432bkt.31 for ; Tue, 28 Aug 2012 02:59:55 -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:x-mailer:thread-index:content-language; bh=t9mHTa9uoirGAwuPloYP93XsP80IWTv33i36aePhzxw=; b=WKs3T62XugBT9CFpBeQpuMVm1hEfmBK7UIMitbyJQiK+Xz5AVX3Jj0ZuvEgZT9DNIg fUQ4NOuoNXoTU2LJUppys1KNBu3cAqYZMmtpf5dUthLcVHGhx7Ar7k70UwsuS2qhrYpp OaNbT0hw0UfrMmIhYuy8euGlSuVRLqSmCqh5/3tfTh09AKwEnp5gDDtyOsKrlte8aHPl BVGb63WreicZYOwOIU2KCX4i/fJNFE7CxTCyUGcMqEJIXMqzQnXiVsiaLCd+6DSSQKDs uleHzCLRj2ReNtHW97q5IRPH9J1nT9tCMg71iabejCUYYSjFV8j+esIhtMPhW1OoXlAR MOMQ== Received: by 10.204.149.217 with SMTP id u25mr4683408bkv.107.1346147994833; Tue, 28 Aug 2012 02:59:54 -0700 (PDT) Received: from RoniE ([109.67.233.208]) by mx.google.com with ESMTPS id fu8sm12250774bkc.5.2012.08.28.02.59.52 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 28 Aug 2012 02:59:54 -0700 (PDT) From: "Roni Even" To: "'Mary Barnes'" , "'CLUE'" References: In-Reply-To: Date: Tue, 28 Aug 2012 12:58:34 +0200 Message-ID: <011f01cd850c$1466b6f0$3d3424d0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0120_01CD851C.D7F04A40" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQDgrTy0AFP2VifBVxG5/Wo85CDdTJlIvUqA Content-Language: en-us Subject: Re: [clue] Tomorrow's design team 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, 28 Aug 2012 09:59:57 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0120_01CD851C.D7F04A40 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On the first item the requirements are also discussed in section 5 of draft-even-clue-rtp-mapping-03 Roni Even From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Mary Barnes Sent: 28 August, 2012 12:35 AM To: CLUE Subject: [clue] Tomorrow's design team meeting The meeting is on for tomorrow. We have lots that we could talk about. We can start going through these and see how far we get and continue discussion on the mailing list and then start back where we left off the following week (or revisit if we think we have some progress). 1) RTP requirements - per http://datatracker.ietf.org/doc/draft-lennox-clue-rtp-usage/ Does everyone agree these are sufficient and if not why and what's missing? 2) RTP topologies - per http://datatracker.ietf.org/doc/draft-even-clue-rtp-mapping/ Are these adequate and comprehensive? 3) Tele-medical use case - http://datatracker.ietf.org/doc/draft-ietf-clue-telepresence-use-cases/ Is this good - any other concerns? 4) Call flows in the framework document? Do we need them? 5) New signaling tickets - per the email I just posted (which isn't yet in the archives) Thanks, Mary. ------=_NextPart_000_0120_01CD851C.D7F04A40 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

On the = first item  the requirements are also discussed in section 5 = of  draft-even-= clue-rtp-mapping-03

 

Roni Even

 

From:= = clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of = Mary Barnes
Sent: 28 August, 2012 12:35 AM
To: = CLUE
Subject: [clue] Tomorrow's design team = meeting

 

The meeting = is on for tomorrow.  We have lots that we could talk about. =  We can start going through these and see how far we get and = continue discussion on the mailing list and then start back where we = left off the following week (or revisit if we think we have some = progress). 

 

  Does everyone agree these are = sufficient and if not why and what's = missing? 

  Are these adequate and = comprehensive? 

  Is this = good - any other concerns? 

4) Call flows in the framework = document?

  Do we = need them?

5) New = signaling tickets - per the email I just posted (which isn't yet in the = archives)

 

Thanks,

Mary.

------=_NextPart_000_0120_01CD851C.D7F04A40-- From ron.even.tlv@gmail.com Tue Aug 28 06:33: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 C433511E808D for ; Tue, 28 Aug 2012 06:33:56 -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.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vn2HiOBdWMrp for ; Tue, 28 Aug 2012 06:33:56 -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 E9EED21F84D9 for ; Tue, 28 Aug 2012 06:33:55 -0700 (PDT) Received: by bkty12 with SMTP id y12so1360525bkt.31 for ; Tue, 28 Aug 2012 06:33: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=w+MCleIJPQ54WT+1ePkBsxKC+Y5Gixz1EIB/+ZOFxOM=; b=DXauH0lR0Fpq2WRikx2XB2OY8ARg3gjWxCqmkHmXuO40QznBDIdIlRD7K+6GhupiIP PefG4dAcVtM8NJDLNWRXCcVno/fNsgd+XdEss4gQw/k9YPX71e68fXLthe8QX7gVNLu9 Q7t0jEDwhzYy2s9K7kC5WrJ/cWHgBMmuc2imiK35ARIuIvBU2+wluUcgW+8eFrj2q8cH 4qq49lmPAx2oTRbFMiu7yY37zRCWHFUoPpp+DhQF+HpT1tJVJG4ViBxKPiCpAAMaWXFP JJmwyCbiZ5TMCDaP7Qr6grPO3U1Ku6wJyE0hp42NYJzPm2VdSt+QICqvnik2NmftqlZ4 nhMQ== Received: by 10.205.125.4 with SMTP id gq4mr4864744bkc.109.1346160834755; Tue, 28 Aug 2012 06:33:54 -0700 (PDT) Received: from RoniE ([109.67.233.208]) by mx.google.com with ESMTPS id he8sm12803515bkc.3.2012.08.28.06.33.52 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 28 Aug 2012 06:33:53 -0700 (PDT) From: "Roni Even" To: "'Christer Holmberg'" , , References: <068.890588ccdb9d1a0b74f5999dd9ddcd35@trac.tools.ietf.org> <7F2072F1E0DE894DA4B517B93C6A0585340A356C46@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585340A356C4F@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585340A356C4F@ESESSCMS0356.eemea.ericsson.se> Date: Tue, 28 Aug 2012 16:32:35 +0200 Message-ID: <013301cd8529$f989bf80$ec9d3e80$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQF6NAOOMUFexABhWpN//DJc6qcskgJ9tsUbAlXWA1GX704osA== Content-Language: en-us Cc: clue@ietf.org Subject: Re: [clue] #14: How do we transport the CLUE information? 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, 28 Aug 2012 13:33:56 -0000 Hi Christer, I think this is part of the challenge and why we need call flows = including SDP. My concern is that some of the information in the = framework are specified using current protocols.=20 I believe that the spatial relation is not specified elsewhere and is = what CLUE is about. As for the rest we will need call flows that address the requirements. = We will also need to verify that there is consistency between the = information specified by different protocols if we cannot have a clear = distinction about what we do in each protocol (CLUE, SDP, RTP/RTCP,XCON, = ....) Roni -----Original Message----- From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of = Christer Holmberg Sent: 28 August, 2012 9:22 AM To: clue-chairs@tools.ietf.org; mary.ietf.barnes@gmail.com Cc: clue@ietf.org Subject: Re: [clue] #14: How do we transport the CLUE information? Correction: content-id shall of course be capture-id. -----Original Message----- From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of = Christer Holmberg Sent: 28. elokuuta 2012 10:18 To: clue issue tracker; clue-chairs@tools.ietf.org; = mary.ietf.barnes@gmail.com Cc: clue@ietf.org Subject: Re: [clue] #14: How do we transport the CLUE information? Hi, A question for clarification: do we assume there will be ONE transport = protocol, or could there possibly be many? I guess it depends on what we really mean by "CLUE information". But, = there could e.g. be some information, needed for CLUE, that we insert in = SDP (there is even a ticket for that), while other information is = transported using some other mechanism. Also, we have been talking about transporting the content-id using some = RTP extension. Regards, Christer -----Original Message----- From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of = clue issue tracker Sent: 28. elokuuta 2012 1:03 To: clue-chairs@tools.ietf.org; mary.ietf.barnes@gmail.com Cc: clue@ietf.org Subject: [clue] #14: How do we transport the CLUE information? #14: How do we transport the CLUE information? What transport protocol should be used for the CLUE specific signaling = information? --=20 --------------------------------+--------------------------- Reporter: mary.ietf.barnes@=E2=80=A6 | Owner: = clue-chairs@=E2=80=A6 Type: task | Status: new Priority: blocker | Milestone: milestone1 Component: charter | Version: 1.0 Severity: - | Keywords: --------------------------------+--------------------------- Ticket URL: 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 rohanse2@cisco.com Tue Aug 28 10:16: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 7D22121F85A3 for ; Tue, 28 Aug 2012 10:16:28 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lgsR6-wQiZMa for ; Tue, 28 Aug 2012 10:16:27 -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 180D621F85A1 for ; Tue, 28 Aug 2012 10:16:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rohanse2@cisco.com; l=4296; q=dns/txt; s=iport; t=1346174187; x=1347383787; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=lD++MVqWwaS2vg3u9x56u7i2pfsKXjlww6auSHj2HKU=; b=ENYtkyvzwolUmtRvnfFcsw4Rvj2cKOTxyi/6RsCIPjen+LF86hqAkGiL CNo//FNegQiuj56XxBm2zBc2dTDPWphiEsAvj0pz+fx7jBwmnXGyJLZTv UEXpilZLMbLbLhoSSzcQ9kgp8gaazyalhlTqGoPAmsfiJxtYN0+9PxRaU g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAJ/7PFCQ/khL/2dsb2JhbABFum6BB4IgAQEBBAEBAQ8BJTYKEQsYCRYPCQMCAQIBFTATBgIBARcHh2sLm0OgR4sIFBCGNQOVVoEUhEiIUoFngmSBVwk X-IronPort-AV: E=Sophos;i="4.80,327,1344211200"; d="scan'208";a="76302400" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 28 Aug 2012 17:16:23 +0000 Received: from [10.47.196.172] ([10.47.196.172]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q7SHGMKJ024020 for ; Tue, 28 Aug 2012 17:16:23 GMT Message-ID: <503CFCF6.8020308@cisco.com> Date: Tue, 28 Aug 2012 18:16:38 +0100 From: Robert Hansen User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 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] Tomorrow's design team 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, 28 Aug 2012 17:16:28 -0000 Notes from the meeting: Participants: Mary Barnes Paul Kyzivat Christer Holmberg Espen Berger John Leslie Jonathon Lennox Roni Even Tom Kristensen Robert Hansen Mary brought up the requirements section of the two RTP documents; Roni clarified that he felt that there should be an explicit requirement that we should use existing protocols where they exist and ensure there is no duplication. There was agreement that this wasn't an RTP-specific requirement, and Mary pointed out that this was already present in the charter. Jonathon clarified that his document only referred to the media plane and RTP - Roni felt that that this was unclear and should be made explicit. There was some further discussion and clarification of the requirements. Roni asked whether requirement 6 (being able to match packets to captures) was strictly an RTP requirement; Jonathon agreed that this was not a purely RTP requirement, but that one of his main aims was to avoid specifying any SDP syntax. There was further discussion of the reliability requirement, with clarification that the actual requirement was that the information was either predefined before the packet was received or was received as part of the packet iself. Finally, Roni asked how SVC would interact with the requirement to only send a single stream to a given decoder. Jonathon explained that the solution would work with this, but that the language needed improving (and that he was referring to a single capture/encoding instantiation rather than to a capture itself). Media capture 8 was contentious, as not all receivers will be able to support moving decode state between decoders (for instance, they could be on seperate hardware, in the extreme case). Roni pointed out that the receiver would need to signal this capability before the provider could take advantage of it. There was debate about whether this requirement was worth including, and if it was whether it needed to add an explicit requirement for this to be signalled or negotiated in signalling. It was clarified that when there was a requirement for a refresh in decoder state this wasn't suggesting a new method for doing so and that RTCP FIR was suitable; CLUE would need to mandate supporting this. Roni also had concerns about the use of the phrase 'as much as possible' when it comes to the use of existing protocols (requirement 10). Jonathon clarified that what he meant was that we should stay within existing protocols and use well-defined extension points CLUE would make new use of the protocols, but as far as possible should, as far as possible, match existing behaviour. There was concern that some middle boxes might have issues with things like generally multiplexing multiple media streams onto a single RTP session, but we have limited control over that. Finally for requirement 12 Jonathon explained why synchronisation was important, and clarified how this could be solved using CNAME in RTCP. At the end of the meeting Paul reiterated that we could really use a term for the capture/encoding instantiations. Rob On 27/08/2012 23:35, Mary Barnes wrote: > The meeting is on for tomorrow. We have lots that we could talk about. > We can start going through these and see how far we get and continue > discussion on the mailing list and then start back where we left off the > following week (or revisit if we think we have some progress). > > 1) RTP requirements - per > http://datatracker.ietf.org/doc/draft-lennox-clue-rtp-usage/ > Does everyone agree these are sufficient and if not why and what's > missing? > 2) RTP topologies - per > http://datatracker.ietf.org/doc/draft-even-clue-rtp-mapping/ > Are these adequate and comprehensive? > 3) Tele-medical use case - > http://datatracker.ietf.org/doc/draft-ietf-clue-telepresence-use-cases/ > Is this good - any other concerns? > 4) Call flows in the framework document? > Do we need them? > 5) New signaling tickets - per the email I just posted (which isn't yet > in the archives) > > Thanks, > Mary. > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From mary.ietf.barnes@gmail.com Tue Aug 28 13:47: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 E340311E80D9 for ; Tue, 28 Aug 2012 13:47:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.686 X-Spam-Level: X-Spam-Status: No, score=-102.686 tagged_above=-999 required=5 tests=[AWL=-0.754, 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t7SHeILpUnMK for ; Tue, 28 Aug 2012 13:47:36 -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 519C211E8099 for ; Tue, 28 Aug 2012 13:47:36 -0700 (PDT) Received: by lahm15 with SMTP id m15so3786639lah.31 for ; Tue, 28 Aug 2012 13:47: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=3R4s2L+OZuP+qe/ZmDNYtWEKChx38bi0hLEiKx3UmO4=; b=nUk4ioLy3pdDGqDcNBqvJpgYQHa2gyAn5Pblp7yq0ekG2z2tF6HezFa/GqJOJgAtFG 2qUGt9+oyuQV+0/T/Vy8fN0x8czhm8fPQlM630GujyfOo52uzDBhMSKHGiJyn0TsNuU1 Z8E06fXY4VfJNuYuM8kPGD11xcGsasYwxGnIYjYD3QcbDnAU/JBhr9NUfwVG9v0IsHz4 X79erOGpRQY/ZrO5V64k2yC4Uy3SAETycfdc4IAi/mknu4fZY4F78oH8QnCA7CcePei+ xt8rzeWnaPkoJddGSmpzH46EvaK4IBbFCByFhtgUIw5rMh0EVqUYW+hVv0Z1cZeQyJoS /MWg== MIME-Version: 1.0 Received: by 10.152.103.146 with SMTP id fw18mr19797639lab.30.1346186854889; Tue, 28 Aug 2012 13:47:34 -0700 (PDT) Received: by 10.112.17.202 with HTTP; Tue, 28 Aug 2012 13:47:34 -0700 (PDT) In-Reply-To: <503CFCF6.8020308@cisco.com> References: <503CFCF6.8020308@cisco.com> Date: Tue, 28 Aug 2012 15:47:34 -0500 Message-ID: From: Mary Barnes To: Robert Hansen Content-Type: multipart/alternative; boundary=f46d040714cf49794c04c8598dfd Cc: clue@ietf.org Subject: Re: [clue] Tomorrow's design team 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, 28 Aug 2012 20:47:38 -0000 --f46d040714cf49794c04c8598dfd Content-Type: text/plain; charset=ISO-8859-1 Rob, Thanks for the taking the notes. This is one session where folks might find it useful (in particular those that couldn't make) to listen to the recording: *Streaming recording link:* https://ietf.webex.com/ietf/ldr.php?AT=pb&SP=MC&rID=7982272&rKey=94b7647395baf2ca *Download recording link:* https://ietf.webex.com/ietf/lsr.php?AT=dw&SP=MC&rID=7982272&rKey=9bedcff4e6dee779 On Tue, Aug 28, 2012 at 12:16 PM, Robert Hansen wrote: > Notes from the meeting: > > Participants: > > Mary Barnes > Paul Kyzivat > Christer Holmberg > Espen Berger > John Leslie > Jonathon Lennox > Roni Even > Tom Kristensen > Robert Hansen > > Mary brought up the requirements section of the two RTP documents; Roni > clarified that he felt that there should be an explicit requirement that we > should use existing protocols where they exist and ensure there is no > duplication. There was agreement that this wasn't an RTP-specific > requirement, and Mary pointed out that this was already present in the > charter. Jonathon clarified that his document only referred to the media > plane and RTP - Roni felt that that this was unclear and should be made > explicit. > > There was some further discussion and clarification of the requirements. > Roni asked whether requirement 6 (being able to match packets to captures) > was strictly an RTP requirement; Jonathon agreed that this was not a purely > RTP requirement, but that one of his main aims was to avoid specifying any > SDP syntax. There was further discussion of the reliability requirement, > with clarification that the actual requirement was that the information was > either predefined before the packet was received or was received as part of > the packet iself. > > Finally, Roni asked how SVC would interact with the requirement to only > send a single stream to a given decoder. Jonathon explained that the > solution would work with this, but that the language needed improving (and > that he was referring to a single capture/encoding instantiation rather > than to a capture itself). > > Media capture 8 was contentious, as not all receivers will be able to > support moving decode state between decoders (for instance, they could be > on seperate hardware, in the extreme case). Roni pointed out that the > receiver would need to signal this capability before the provider could > take advantage of it. There was debate about whether this requirement was > worth including, and if it was whether it needed to add an explicit > requirement for this to be signalled or negotiated in signalling. > > It was clarified that when there was a requirement for a refresh in > decoder state this wasn't suggesting a new method for doing so and that > RTCP FIR was suitable; CLUE would need to mandate supporting this. Roni > also had concerns about the use of the phrase 'as much as possible' when it > comes to the use of existing protocols (requirement 10). Jonathon clarified > that what he meant was that we should stay within existing protocols and > use well-defined extension points CLUE would make new use of the protocols, > but as far as possible should, as far as possible, match existing > behaviour. There was concern that some middle boxes might have issues with > things like generally multiplexing multiple media streams onto a single RTP > session, but we have limited control over that. > > Finally for requirement 12 Jonathon explained why synchronisation was > important, and clarified how this could be solved using CNAME in RTCP. > > At the end of the meeting Paul reiterated that we could really use a term > for the capture/encoding instantiations. > > Rob > > > On 27/08/2012 23:35, Mary Barnes wrote: > >> The meeting is on for tomorrow. We have lots that we could talk about. >> We can start going through these and see how far we get and continue >> discussion on the mailing list and then start back where we left off the >> following week (or revisit if we think we have some progress). >> >> 1) RTP requirements - per >> http://datatracker.ietf.org/**doc/draft-lennox-clue-rtp-**usage/ >> Does everyone agree these are sufficient and if not why and what's >> missing? >> 2) RTP topologies - per >> http://datatracker.ietf.org/**doc/draft-even-clue-rtp-**mapping/ >> Are these adequate and comprehensive? >> 3) Tele-medical use case - >> http://datatracker.ietf.org/**doc/draft-ietf-clue-** >> telepresence-use-cases/ >> Is this good - any other concerns? >> 4) Call flows in the framework document? >> Do we need them? >> 5) New signaling tickets - per the email I just posted (which isn't yet >> in the archives) >> >> 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 > --f46d040714cf49794c04c8598dfd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Rob,

Thanks for the taking the notes. =A0This is one ses= sion where folks might find it useful (in particular those that couldn'= t make) to listen to the recording:

Streaming recording link:
https://ietf.webex.com/ietf/ldr.php?AT=3Dpb&SP=3DMC&rID=3D7982272&= amp;rKey=3D94b7647395baf2ca
Download recording link:
 =A0
https://ietf.webex.com/ietf/lsr.php?AT=3Ddw&SP=3DMC&rID=3D798= 2272&rKey=3D9bedcff4e6dee779


On Tue, Aug= 28, 2012 at 12:16 PM, Robert Hansen <rohanse2@cisco.com> w= rote:
Notes from the meeting:

Participants:

Mary Barnes
Paul Kyzivat
Christer Holmberg
Espen Berger
John Leslie
Jonathon Lennox
Roni Even
Tom Kristensen
Robert Hansen

Mary brought up the requirements section of the two RTP documents; Roni cla= rified that he felt that there should be an explicit requirement that we sh= ould use existing protocols where they exist and ensure there is no duplica= tion. There was agreement that this wasn't an RTP-specific requirement,= and Mary pointed out that this was already present in the charter. Jonatho= n clarified that his document only referred to the media plane and RTP - Ro= ni felt that that this was unclear and should be made explicit.

There was some further discussion and clarification of the requirements. Ro= ni asked whether requirement 6 (being able to match packets to captures) wa= s strictly an RTP requirement; Jonathon agreed that this was not a purely R= TP requirement, but that one of his main aims was to avoid specifying any S= DP syntax. There was further discussion of the reliability requirement, wit= h clarification that the actual requirement was that the information was ei= ther predefined before the packet was received or was received as part of t= he packet iself.

Finally, Roni asked how SVC would interact with the requirement to only sen= d a single stream to a given decoder. Jonathon explained that the solution = would work with this, but that the language needed improving (and that he w= as referring to a single capture/encoding instantiation rather than to a ca= pture itself).

Media capture 8 was contentious, as not all receivers will be able to suppo= rt moving decode state between decoders (for instance, they could be on sep= erate hardware, in the extreme case). Roni pointed out that the receiver wo= uld need to signal this capability before the provider could take advantage= of it. There was debate about whether this requirement was worth including= , and if it was whether it needed to add an explicit requirement for this t= o be signalled or negotiated in signalling.

It was clarified that when there was a requirement for a refresh in decoder= state this wasn't suggesting a new method for doing so and that RTCP F= IR was suitable; CLUE would need to mandate supporting this. Roni also had = concerns about the use of the phrase 'as much as possible' when it = comes to the use of existing protocols (requirement 10). Jonathon clarified= that what he meant was that we should stay within existing protocols and u= se well-defined extension points CLUE would make new use of the protocols, = but as far as possible should, as far as possible, match existing behaviour= . There was concern that some middle boxes might have issues with things li= ke generally multiplexing multiple media streams onto a single RTP session,= but we have limited control over that.

Finally for requirement 12 Jonathon explained why synchronisation was impor= tant, and clarified how this could be solved using CNAME in RTCP.

At the end of the meeting Paul reiterated that we could really use a term f= or the capture/encoding instantiations.

Rob


On 27/08/2012 23:35, Mary Barnes wrote:
The meeting is on for tomorrow. =A0We have lots that we could talk about. =A0 We can start going through these and see how far we get and continue discussion on the mailing list and then start back where we left off the following week (or revisit if we think we have some progress).

1) RTP requirements - per
http://datatracker.ietf.org/doc/draft-lennox-clue-rt= p-usage/
=A0 =A0Does everyone agree these are sufficient and if not why and what'= ;s
missing?
2) RTP topologies - per
http://datatracker.ietf.org/doc/draft-even-clue-rtp-= mapping/
=A0 =A0Are these adequate and comprehensive?
3) Tele-medical use case -
http://datatracker.ietf.org/doc/draft-iet= f-clue-telepresence-use-cases/
=A0 =A0Is this good - any other concerns?
4) Call flows in the framework document?
=A0 =A0Do we need them?
5) New signaling tickets - per the email I just posted (which isn't yet=
in the archives)

Thanks,
Mary.


_______________________________________________
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

--f46d040714cf49794c04c8598dfd-- From mary.ietf.barnes@gmail.com Wed Aug 29 07:34:01 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 3777E21F86D4; Wed, 29 Aug 2012 07:34:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.513 X-Spam-Level: X-Spam-Status: No, score=-103.513 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tDx8MnsrzzGr; Wed, 29 Aug 2012 07:34:00 -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 54AED21F86D1; Wed, 29 Aug 2012 07:33:59 -0700 (PDT) Received: by lahm15 with SMTP id m15so819204lah.31 for ; Wed, 29 Aug 2012 07:33:58 -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=ju6X+PO6r8gqreTHZ1RaYiI7GRXJfXvM7WCpLZQ8oTo=; b=e2kXxk8daTveuQCitC8VXXuthJikJ+C4/K4oBi64g9fkSG3rObEfcAE5GPOA/my6dq nwFS6PMdJhRL8CKhX6Bjm8I8ACqnTbyqzpEvIWYsgyHcn/N7pjrX4+hjtJ5j9PxXaekl A/RFueWFdimm7qWsGxlctVROSlviPom6z9UXA8aYzNX36AJ8lZZZU1e82cL2CzNiZ0lG KAEp1J1QOROldVYIy5zDGIEd9xL+jATmPj6fZzL+Qd7fo3G3X0KlQXvVh2Uy9YIYi5P6 0F3Fh2E1QaR15K51tqMA28KhOGc3gTscIPfJ3rPpZC8BZJxhczaMbcUDvsbcHBwlTjsq yRKQ== MIME-Version: 1.0 Received: by 10.112.86.169 with SMTP id q9mr445615lbz.65.1346250838276; Wed, 29 Aug 2012 07:33:58 -0700 (PDT) Received: by 10.112.17.202 with HTTP; Wed, 29 Aug 2012 07:33:58 -0700 (PDT) In-Reply-To: <20120827231317.20792.2158.idtracker@ietfa.amsl.com> References: <20120827231317.20792.2158.idtracker@ietfa.amsl.com> Date: Wed, 29 Aug 2012 09:33:58 -0500 Message-ID: From: Mary Barnes To: CLUE , DISPATCH , rai@ietf.org Content-Type: multipart/alternative; boundary=f46d0401fae9fe7b8904c86872b9 Subject: [clue] Fwd: NomCom 2012-2013: Call for Nominations 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, 29 Aug 2012 14:34:01 -0000 --f46d0401fae9fe7b8904c86872b9 Content-Type: text/plain; charset=ISO-8859-1 Please consider making nominations for the open positions (including RAI AD). The Nomcom needs a pool of qualified individuals to do their job well and you can nominate more than one person for a given position. You'll have a chance to provide additional input on all the nominees once the call for nominations closes. Mary. ---------- Forwarded message ---------- From: NomCom Chair Date: Mon, Aug 27, 2012 at 6:13 PM Subject: NomCom 2012-2013: Call for Nominations To: IETF Announcement List The 2012-2013 Nominating Committee (NomCom) is seeking nominations from now until September 24, 2012 . The open positions being considered by this year's NomCom can be found at the end of this email or on the NomCom 2012-2013 website: https://www.ietf.org/group/nomcom/2012/ Nominations may be made by selecting the Nominate link at the top of the NomCom 2012-2013 website or by visiting the following URL: https://www.ietf.org/group/nomcom/2012/nominate Note that nominations made using the web tool require an ietf.org (i.e., datatracker) account. You can create an ietf.org account by visiting the following URL: https://datatracker.ietf.org/accounts/create/ Nominations may also be made by email to nomcom12@ietf.org. If you do so, please include the word "Nominate" in the Subject and indicate in the email who is being nominated, their email address (to confirm acceptance of the nomination), and the position for which you are making the nomination. If you wish to nominate someone via email for more than one position, please use separate emails to do so. Self nomination is welcome. NomCom 2012-2013 will follow the policy for "Open Disclosure of Willing Nominees" described in RFC 5680. As stated in RFC 5680: "The list of nominees willing to be considered for positions under review in the current NomCom cycle is not confidential". Willing Nominees for each position will be publicly listed. With the exception of publicly listing willing nominees, the confidentiality requirements of RFC 3777 remain in effect. All feedback and NomCom deliberations will remain confidential and will not be disclosed. In order to ensure time to collect sufficient community feedback about each of the willing nominees, nominations must be received by the NomCom on or before September 24, 2012. The NomCom appoints individuals to fill the open slots on the IAOC, the IAB, and the IESG. This year, the NomCom willing be filling the positions currently held by the following individuals, whose terms expire in March 2013: IAOC: -------- Dave Crocker IAB: -------- Alissa Cooper Joel Halpern David Kessens Danny McPherson Jon Peterson Dave Thaler IESG: -------- Russ Housley (IETF Chair) Pete Resnick (Applications Area) Ralph Droms (Internet Area) Ronald Bonica (Operations and Management Area) Robert Sparks (Real-Time Applications and Infrastructure Area) Adrian Farrel (Routing Area) Stephen Farrell (Security Area) Wesley Eddy (Transport Area) In addition to nominations, the Nominating Committee is actively seeking community input on the jobs that need to be filled. We have received the job descriptions from the IAB, IESG, and IAOC and they can be found at: https://www.ietf.org/group/nomcom/2012/iaoc-requirements https://www.ietf.org/group/nomcom/2012/iab-requirements https://www.ietf.org/group/nomcom/2012/chair-requirements https://www.ietf.org/group/nomcom/2012/iesg-requirements However, we also need the community's views and input on the jobs within each organization. If you have ideas on job responsibilities (more, less, different), please let us know. Please send suggestions and feedback to nomcom12@ietf.org. Thank you for your help in identifying qualified nominees. Matt Lepinski nomcom-chair@ietf.org --f46d0401fae9fe7b8904c86872b9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Please consider making nominations for the open positions (including RAI AD= ). =A0 The Nomcom needs a pool of qualified individuals to do their job wel= l and you can nominate more than one person for a given position. =A0You= 9;ll have a chance to provide additional input on all the nominees once the= call for nominations closes.

Mary.=A0

---------- Forwar= ded message ----------
From: NomCom Chair<= /b> <nomcom-c= hair@ietf.org>
Date: Mon, Aug 27, 2012 at 6:13 PM
Subject: NomCom 2012-2013: Call for N= ominations
To: IETF Announcement List <ietf-announce@ietf.org>


The 2012-2013 Nominat= ing Committee (NomCom) is seeking nominations
from now until September 24, 2012 . The open positions being considered
by this year's NomCom can be found at the end of this email or on the NomCom 2012-2013 website:

https= ://www.ietf.org/group/nomcom/2012/

Nominations may be made by selecting the Nominate link at the top of
the NomCom 2012-2013 website or by visiting the following URL:

https://www.ietf.org/group/nomcom/2012/nominate

Note that nominations made using the web tool require an ietf.org (i.e.,
datatracker) account. You can create an ietf.org account by visiting the
following URL:

https://datatracker.ietf.org/accounts/create/

Nominations may also be made by email to nomcom12@ietf.org.
If you do so, please include the word "Nominate" in the Subject a= nd
indicate in the email who is being nominated, their email address (to
confirm acceptance of the nomination), and the position for which you
are making the nomination. If you wish to nominate someone via email
for more than one position, please use separate emails to do so.

Self nomination is welcome.

NomCom 2012-2013 will follow the policy for "Open Disclosure of Willin= g
Nominees" described in RFC 5680. =A0As stated in RFC 5680: "The l= ist of
nominees willing to be considered for positions under review in the
current NomCom cycle is not confidential". Willing Nominees for each position will be publicly listed.

With the exception of publicly listing willing nominees, the
confidentiality requirements of RFC 3777 remain in effect. =A0All
feedback and NomCom deliberations will remain confidential and
will not be disclosed.

In order to ensure time to collect sufficient community feedback about
each of the willing nominees, nominations must be received by the
NomCom on or before September 24, 2012.

The NomCom appoints individuals to fill the open slots on the
IAOC, the IAB, and the IESG. This year, the NomCom willing be filling the positions currently held by the following individuals, whose terms expire in March 2013:

IAOC:
--------
Dave Crocker

IAB:
--------
Alissa Cooper
Joel Halpern
David Kessens
Danny McPherson
Jon Peterson
Dave Thaler

IESG:
--------
Russ Housley =A0(IETF Chair)
Pete Resnick =A0(Applications Area)
Ralph Droms =A0(Internet Area)
Ronald Bonica =A0(Operations and Management Area)
Robert Sparks =A0(Real-Time Applications and Infrastructure Area)
Adrian Farrel =A0(Routing Area)
Stephen Farrell =A0(Security Area)
Wesley Eddy =A0(Transport Area)

In addition to nominations, the Nominating Committee is actively
seeking community input on the jobs that need to be filled. =A0We have
received the job descriptions from the IAB, IESG, and IAOC and they can
be found at:

https://www.ietf.org/group/nomcom/2012/iaoc-requirements https://www.ietf.org/group/nomcom/2012/iab-requirements
https://www.ietf.org/group/nomcom/2012/chair-requirements<= br> https://www.ietf.org/group/nomcom/2012/iesg-requirements
However, we also need the community's views and input on the jobs
within each organization. If you have ideas on job responsibilities
(more, less, different), please let us know. =A0Please send suggestions
and feedback to nomcom12@ietf.org.=

Thank you for your help in identifying qualified nominees.

Matt Lepinski
nomcom-chair@ietf.org

--f46d0401fae9fe7b8904c86872b9-- From trac+clue@trac.tools.ietf.org Wed Aug 29 11:04: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 C86F621F86F4 for ; Wed, 29 Aug 2012 11:04:48 -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, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nr5C0gBj+jvd for ; Wed, 29 Aug 2012 11:04:48 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 348EF21F86F0 for ; Wed, 29 Aug 2012 11:04:48 -0700 (PDT) Received: from localhost ([127.0.0.1]:56639 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1T6mcp-0002gH-FL; Wed, 29 Aug 2012 20:04:23 +0200 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, pkyzivat@alum.mit.edu X-Trac-Project: clue Date: Wed, 29 Aug 2012 18:04:23 -0000 X-URL: http://tools.ietf.org/wg/clue/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/clue/trac/ticket/16 Message-ID: <063.e267b5f53214b9814e5c7ad751f09f3f@trac.tools.ietf.org> X-Trac-Ticket-ID: 16 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-clue-framework@tools.ietf.org, pkyzivat@alum.mit.edu, clue@ietf.org X-SA-Exim-Mail-From: trac+clue@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: allyn@cisco.com, apeppere@gmail.com, bbaldino@cisco.com, mark.duckworth@polycom.com Resent-Message-Id: <20120829180448.348EF21F86F0@ietfa.amsl.com> Resent-Date: Wed, 29 Aug 2012 11:04:48 -0700 (PDT) Resent-From: trac+clue@trac.tools.ietf.org Cc: clue@ietf.org Subject: [clue] #16: Need a term for a particular encoding of a capture 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: Wed, 29 Aug 2012 18:04:48 -0000 #16: Need a term for a particular encoding of a capture We keep encountering places where the term "capture" is used but where what is meant is a specific encoding of a capture. (It is possible to request/send multiple encodings of the same capture.) We need a specific term, and definition, for this concept. This should be in the framework, and it and other documents should be fixed to use this new term where appropriate. -- ------------------------+----------------------------------------- Reporter: pkyzivat@… | Owner: draft-ietf-clue-framework@… Type: task | Status: new Priority: major | Milestone: milestone1 Component: framework | Version: 1.0 Severity: - | Keywords: ------------------------+----------------------------------------- Ticket URL: clue From pkyzivat@alum.mit.edu Thu Aug 30 14:51: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 62C7721F8535 for ; Thu, 30 Aug 2012 14:51:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.154 X-Spam-Level: X-Spam-Status: No, score=-1.154 tagged_above=-999 required=5 tests=[AWL=-0.717, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PvMzIbagS6YO for ; Thu, 30 Aug 2012 14:51:57 -0700 (PDT) Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:24]) by ietfa.amsl.com (Postfix) with ESMTP id 9781621F8534 for ; Thu, 30 Aug 2012 14:51:57 -0700 (PDT) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta02.westchester.pa.mail.comcast.net with comcast id syyy1j0071ap0As519s0cU; Thu, 30 Aug 2012 21:52:00 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta22.westchester.pa.mail.comcast.net with comcast id t9sP1j0023ZTu2S3i9sPpv; Thu, 30 Aug 2012 21:52:23 +0000 Message-ID: <503FE07A.70609@alum.mit.edu> Date: Thu, 30 Aug 2012 17:51:54 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: CLUE Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [clue] Thoughts on issues #12/#13 - what goes in SDP? 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, 30 Aug 2012 21:51:58 -0000 (As individual) Issues 12 & 13 ask how we separate what data should be carried in SDP vs. what should be in clue-specific signaling. I've been thinking about that, and while I don't have any answers I do have some thoughts to share that might help decide this. One difference between the SDP and the CLUE-specific signaling is that the SDP is governed by the O/A mechanism, while the clue signaling is governed by the Advertisement/Configuration mechanism. Of course we can change the mechanism for the clue signaling if we want, but for the time being I'll assume we leave that mechanism as-is. There must be a coupling between the two. At the very least, before transmission can begin in response to a new configuration message, the negotiated SDP must be sufficient to support that. If the SDP in effect *before* sending that configuration is not sufficient, then a new O/A will need to be performed, and transmission according to the new configuration can't begin until that O/A is complete. One approach to this would be to require an advertiser to constrain what it advertises to things that are covered by currently negotiated SDP. This then ensures that any configurations selected from that advertisement can be done without another O/A. But it may also require SDP demanding more resources (e.g. bandwidth) than will be required in practice. Another approach would be to defer any needed adjustments to SDP until a configuration is received by the advertiser. It could then initiate any SDP changes needed to support that configuration. This allows the SDP configuration to be tuned to what is needed for the particular configuration. A downside is that if the O/A then fails, what should happen? Those are extremes. Between them are possibilities to do adjustments from the receiving end before sending the configuration, and probably other ways. Which approach is taken seems likely to profoundly impact the decision about what which information can be in the SDP rather than the clue messages. This gets more complex when you consider that advertisements and configurations are flowing in both directions. If we aren't careful we may end up needing an O/A exchange for each advertisement or configuration. (But maybe this doesn't matter.) At the very least, it's important that it be clear which side is responsible for initiating an O/A required by any clue message. Thanks, Paul From mary.ietf.barnes@gmail.com Fri Aug 31 10:24:18 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 B340221F8627 for ; Fri, 31 Aug 2012 10:24:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.516 X-Spam-Level: X-Spam-Status: No, score=-103.516 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HG7X-z-wJDbm for ; Fri, 31 Aug 2012 10:24:17 -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 76B7821F852D for ; Fri, 31 Aug 2012 10:24:17 -0700 (PDT) Received: by lbky2 with SMTP id y2so1663556lbk.31 for ; Fri, 31 Aug 2012 10:24:16 -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=WWAuClnyOxFYzskLrkHYqdm/sL4RExUoH+pE6VAAI90=; b=PBJC5KDPx3asy+VOSNVR8aN35G2ul5LUimJTn3nTWiy4a3hawlSX+HTShgoAlwQ2Fb 9zf4S5kOovrRJQpWeYjt6Qtk/Kqpu+mfJXdYpiI9C1PWq9r27kuVNhBgtc9hCFPQ3prH 0zJjETAeSDQLY5JwSvaFCv/wyyiz5rwvUeIAVdiGQy2/e14Ek2phP5QIbmWcHRsN12OK uibVwXDN/DPvr9CQ/epOwjk/71MT9eObCsPCzfBaWMTpUPSqpg/ycfVepjQCnmrS3US8 6uMGjT7KKZu8quLUg739rqMXljFYSc6LO/X3ZlZCKwLJ21KnO+MkxG3d8i0vHB9LFJ+E OUJg== MIME-Version: 1.0 Received: by 10.112.17.161 with SMTP id p1mr1053057lbd.64.1346433856044; Fri, 31 Aug 2012 10:24:16 -0700 (PDT) Received: by 10.112.17.202 with HTTP; Fri, 31 Aug 2012 10:24:16 -0700 (PDT) Date: Fri, 31 Aug 2012 12:24:16 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=bcaec554d322b3fd5f04c8930f8c Subject: [clue] CLUE WG Interim meeting - Details and Draft agenda 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, 31 Aug 2012 17:24:18 -0000 --bcaec554d322b3fd5f04c8930f8c Content-Type: text/plain; charset=ISO-8859-1 Hi all, I have updated the wiki with information for the Interim Meeting Sept. 19-20, 2012: http://trac.tools.ietf.org/wg/clue/trac/wiki/WikiStart There is a draft agenda which will be populated to point to documents that are submitted, as well as relevant email threads before the meeting. Please note the deadlines are as follows: - Request Agenda time: Wednesday, Sept. 12, 2012 (5pm Pacific) - Draft Deadline: Wednesday, Sept. 12, 2012 (5pm Pacific) - Revised agenda: Thursday, Sept. 13, 2012 (5pm Pacific) - Presentation deadline: Friday, Sept. 14, 2012 (5pm Pacific) - Final agenda (day 1): Monday, Sept. 17, 2012 (noon Pacific) - Final agenda (day 2): Wednesday,Sept. 19, 2012 (10pm Pacific) Note, that I will organize a (un-hosted) group dinner at Macaroni Grill for the 19th, so please respond to the doodle if you would like to attend: http://www.doodle.com/nar2u3783xsxaxk7 Also, if you did not respond to the original doodle and will attend, please fill out the doodle: http://www.doodle.com/uzb9nf2h92dqfp5i If you will be attending remotely, please let us know. We will schedule a Webex and post those details shortly. Regards, Mary. --bcaec554d322b3fd5f04c8930f8c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all,

I have updated the wiki with information for the= Interim Meeting Sept. 19-20, 2012:

There is a draft agenda which will be populated to poin= t to documents that are submitted, as well as relevant email threads before= the meeting. =A0Please note the deadlines are as follows:
  • Request Agenda time: Wednesday, Sept. 12, 2012 (5pm Pacific)
  • Dr= aft Deadline: Wednesday, Sept. 12, 2012 (5pm Pacific)
  • Revised agend= a: Thursday, Sept. 13, 2012 (5pm Pacific)
  • Presentation deadline: Fr= iday, Sept. 14, 2012 (5pm Pacific)
  • Final agenda (day 1): Monday, Sept. 17, 2012 (noon Pacific)
  • Fin= al agenda (day 2): Wednesday,Sept. 19, 2012 (10pm Pacific)
=
Note, that I will organize a (un-hosted) group dinner at Macaron= i Grill for the 19th, so please respond to the doodle if you would like to = attend:

Also, if you did not respo= nd to the original doodle and will attend, please fill out the doodle:

If you will be attendi= ng remotely, please let us know. =A0We will schedule a Webex and post those= details shortly.

Regards,
Mary. =A0
--bcaec554d322b3fd5f04c8930f8c-- From christer.holmberg@ericsson.com Fri Aug 31 10:57: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 D0FAA21F8627 for ; Fri, 31 Aug 2012 10:57:36 -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.087, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2sd+tIBt2G-A for ; Fri, 31 Aug 2012 10:57:36 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 8C60B21F8624 for ; Fri, 31 Aug 2012 10:57:35 -0700 (PDT) X-AuditID: c1b4fb2d-b7fea6d000002ccb-70-5040fb0e363c Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 15.17.11467.E0BF0405; Fri, 31 Aug 2012 19:57:34 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.99]) by esessmw0184.eemea.ericsson.se ([10.2.3.53]) with mapi; Fri, 31 Aug 2012 19:57:34 +0200 From: Christer Holmberg To: Paul Kyzivat , CLUE Date: Fri, 31 Aug 2012 19:53:19 +0200 Thread-Topic: [clue] Thoughts on issues #12/#13 - what goes in SDP? Thread-Index: Ac2G+a/qTm4hVh4ZTdOopIsfBEql2gAp9F+b Message-ID: <7F2072F1E0DE894DA4B517B93C6A05853409FF2F66@ESESSCMS0356.eemea.ericsson.se> References: <503FE07A.70609@alum.mit.edu> In-Reply-To: <503FE07A.70609@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: H4sIAAAAAAAAA+NgFjrNLMWRmVeSWpSXmKPExsUyM+JvrS7fb4cAg99PBCz2n7rMbLFiwwFW ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugSvj3eGJjAVtEhXbF79hbmA8IdzFyMkhIWAi cWnTAyYIW0ziwr31bF2MXBxCAqcYJbaeec4I4cxhlPj47QdQFQcHm4CFRPc/bZAGEQE7iflb rrKC2CwCqhIf521hAbGFBZwkHn6YxQJR4yyx/OYVJgjbSKJ5xyI2EJtXIFxi8eOdYDVCApoS 85/dYQcZzymgJfHjmi1ImBHonu+n1oC1MguIS9x6Mh/qTgGJJXvOM0PYohIvH/9jhagXlbjT vp4Rol5HYsHuT2wQtrbEsoWvmSHWCkqcnPmEZQKj6CwkY2chaZmFpGUWkpYFjCyrGIVzEzNz 0ssN9VKLMpOLi/Pz9IpTNzECI+Tglt+6OxhPnRM5xCjNwaIkzsuVtN9fSCA9sSQ1OzW1ILUo vqg0J7X4ECMTB6dUA2NgkRJbbF+YYbH9BbXkiYFFm6IWnW58vyZT/Pci5eti+j+itnkoXH54 pdE+vWHSTqnElxP+ODkYSnz5M+/WM20WzUkbF7gyTni9SMTQd2rn6jeN5ROfd1yRduZ8lHbq 9Pm4G6ee9Oz69uV6CcNlhsCDM/w1vG9muq2ZlZgqomqzVbDk8ePf/N+VWIozEg21mIuKEwGc g2qvXgIAAA== Subject: Re: [clue] Thoughts on issues #12/#13 - what goes in SDP? 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, 31 Aug 2012 17:57:36 -0000 Hi, I don't think CLUE signalling will be used only for adv/conf. I guess we ma= y also use it for certain types of indications - perhaps even some type of = controlling messages. Regards, Christer ________________________________________ From: clue-bounces@ietf.org [clue-bounces@ietf.org] On Behalf Of Paul Kyziv= at [pkyzivat@alum.mit.edu] Sent: Friday, August 31, 2012 12:51 AM To: CLUE Subject: [clue] Thoughts on issues #12/#13 - what goes in SDP? (As individual) Issues 12 & 13 ask how we separate what data should be carried in SDP vs. what should be in clue-specific signaling. I've been thinking about that, and while I don't have any answers I do have some thoughts to share that might help decide this. One difference between the SDP and the CLUE-specific signaling is that the SDP is governed by the O/A mechanism, while the clue signaling is governed by the Advertisement/Configuration mechanism. Of course we can change the mechanism for the clue signaling if we want, but for the time being I'll assume we leave that mechanism as-is. There must be a coupling between the two. At the very least, before transmission can begin in response to a new configuration message, the negotiated SDP must be sufficient to support that. If the SDP in effect *before* sending that configuration is not sufficient, then a new O/A will need to be performed, and transmission according to the new configuration can't begin until that O/A is complete. One approach to this would be to require an advertiser to constrain what it advertises to things that are covered by currently negotiated SDP. This then ensures that any configurations selected from that advertisement can be done without another O/A. But it may also require SDP demanding more resources (e.g. bandwidth) than will be required in practice. Another approach would be to defer any needed adjustments to SDP until a configuration is received by the advertiser. It could then initiate any SDP changes needed to support that configuration. This allows the SDP configuration to be tuned to what is needed for the particular configuration. A downside is that if the O/A then fails, what should happen= ? Those are extremes. Between them are possibilities to do adjustments from the receiving end before sending the configuration, and probably other ways. Which approach is taken seems likely to profoundly impact the decision about what which information can be in the SDP rather than the clue messages. This gets more complex when you consider that advertisements and configurations are flowing in both directions. If we aren't careful we may end up needing an O/A exchange for each advertisement or configuration. (But maybe this doesn't matter.) At the very least, it's important that it be clear which side is responsible for initiating an O/A required by any clue message. Thanks, Paul _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue= From pkyzivat@alum.mit.edu Fri Aug 31 11: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 E9A4E21F855B for ; Fri, 31 Aug 2012 11:10:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.148 X-Spam-Level: X-Spam-Status: No, score=-1.148 tagged_above=-999 required=5 tests=[AWL=-0.711, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rxCZ4jcLjTkF for ; Fri, 31 Aug 2012 11:10:37 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 3378521F8554 for ; Fri, 31 Aug 2012 11:10:35 -0700 (PDT) Received: from omta19.westchester.pa.mail.comcast.net ([76.96.62.98]) by qmta03.westchester.pa.mail.comcast.net with comcast id tN4R1j00627AodY53WAf2A; Fri, 31 Aug 2012 18:10:39 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta19.westchester.pa.mail.comcast.net with comcast id tWAu1j00l3ZTu2S3fWAueh; Fri, 31 Aug 2012 18:10:55 +0000 Message-ID: <5040FE1A.1060700@alum.mit.edu> Date: Fri, 31 Aug 2012 14:10:34 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: Christer Holmberg References: <503FE07A.70609@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05853409FF2F66@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05853409FF2F66@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: CLUE Subject: Re: [clue] Thoughts on issues #12/#13 - what goes in SDP? 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, 31 Aug 2012 18:10:38 -0000 On 8/31/12 1:53 PM, Christer Holmberg wrote: > Hi, > > I don't think CLUE signalling will be used only for adv/conf. I guess we may also use it for certain types of indications - perhaps even some type of controlling messages. I suppose that's possible, though AFAIK nothing of that sort has yet been proposed. But it's irrelevant to the point I was making, which is about which info should go in Adv/Conf and which should go in SDP. Thanks, Paul > Regards, > > Christer > > ________________________________________ > From: clue-bounces@ietf.org [clue-bounces@ietf.org] On Behalf Of Paul Kyzivat [pkyzivat@alum.mit.edu] > Sent: Friday, August 31, 2012 12:51 AM > To: CLUE > Subject: [clue] Thoughts on issues #12/#13 - what goes in SDP? > > (As individual) > > Issues 12 & 13 ask how we separate what data should be carried in SDP > vs. what should be in clue-specific signaling. I've been thinking about > that, and while I don't have any answers I do have some thoughts to > share that might help decide this. > > One difference between the SDP and the CLUE-specific signaling is that > the SDP is governed by the O/A mechanism, while the clue signaling is > governed by the Advertisement/Configuration mechanism. Of course we can > change the mechanism for the clue signaling if we want, but for the time > being I'll assume we leave that mechanism as-is. > > There must be a coupling between the two. At the very least, before > transmission can begin in response to a new configuration message, the > negotiated SDP must be sufficient to support that. If the SDP in effect > *before* sending that configuration is not sufficient, then a new O/A > will need to be performed, and transmission according to the new > configuration can't begin until that O/A is complete. > > One approach to this would be to require an advertiser to constrain what > it advertises to things that are covered by currently negotiated SDP. > This then ensures that any configurations selected from that > advertisement can be done without another O/A. But it may also require > SDP demanding more resources (e.g. bandwidth) than will be required in > practice. > > Another approach would be to defer any needed adjustments to SDP until a > configuration is received by the advertiser. It could then initiate any > SDP changes needed to support that configuration. This allows the SDP > configuration to be tuned to what is needed for the particular > configuration. A downside is that if the O/A then fails, what should happen? > > Those are extremes. Between them are possibilities to do adjustments > from the receiving end before sending the configuration, and probably > other ways. > > Which approach is taken seems likely to profoundly impact the decision > about what which information can be in the SDP rather than the clue > messages. > > This gets more complex when you consider that advertisements and > configurations are flowing in both directions. If we aren't careful we > may end up needing an O/A exchange for each advertisement or > configuration. (But maybe this doesn't matter.) > > At the very least, it's important that it be clear which side is > responsible for initiating an O/A required by any clue message. > > Thanks, > Paul > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From christer.holmberg@ericsson.com Fri Aug 31 12:17: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 13B5A21F8578 for ; Fri, 31 Aug 2012 12:17:09 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mif4-qWMhBsw for ; Fri, 31 Aug 2012 12:17:08 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id BE78221F8577 for ; Fri, 31 Aug 2012 12:17:07 -0700 (PDT) X-AuditID: c1b4fb2d-b7fea6d000002ccb-86-50410db28cbe Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id CD.1C.11467.2BD01405; Fri, 31 Aug 2012 21:17:06 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.99]) by esessmw0247.eemea.ericsson.se ([153.88.115.93]) with mapi; Fri, 31 Aug 2012 21:16:45 +0200 From: Christer Holmberg To: Paul Kyzivat Date: Fri, 31 Aug 2012 21:14:21 +0200 Thread-Topic: [clue] Thoughts on issues #12/#13 - what goes in SDP? Thread-Index: Ac2Ho+snitKx+h0kSymHmRrxg9mBowACOhp8 Message-ID: <7F2072F1E0DE894DA4B517B93C6A05853409FF2F6C@ESESSCMS0356.eemea.ericsson.se> References: <503FE07A.70609@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05853409FF2F66@ESESSCMS0356.eemea.ericsson.se>, <5040FE1A.1060700@alum.mit.edu> In-Reply-To: <5040FE1A.1060700@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: H4sIAAAAAAAAA+NgFrrKLMWRmVeSWpSXmKPExsUyM+Jvre4mXscAg7OzJSz2n7rMbLFiwwFW ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugStj7YTVLAVXZSp+b/jN1sDYLN7FyMkhIWAi 8erCd1YIW0ziwr31bF2MXBxCAqcYJV7v+wOWEBJYwCgxYbZgFyMHB5uAhUT3P20QU0RAQ2LS VjWQCmYBCYlVFz8wgoRZBFQlujd5gYSFBZwkHn6YxQJiiwg4Syy/eYUJwjaSWL/+MBuIzSsQ LnG76TsjxNbpjBI3G/+zgczhFNCRmHQ3GaSGEeiy76fWMEGsEpe49WQ+E8TFAhJL9pxnhrBF JV4+/scKUS8qcad9PSNEvY7Egt2f2CBsbYllC18zQ+wVlDg58wnLBEaxWUjGzkLSMgtJyywk LQsYWVYxCucmZuaklxvqpRZlJhcX5+fpFaduYgRGzcEtv3V3MJ46J3KIUZqDRUmclytpv7+Q QHpiSWp2ampBalF8UWlOavEhRiYOTqkGRhOVsAmZTIuPrXtpapd9eaLSBt+m1h9ZC08FlTm6 srKfSrkx7c/Txf/mM/5h3/IlI79d/FCa69qVRtLvGr5tLrHYX7K+8EE3z8QzBx8LyJypW6PP KXgtlq/tzad+yQdl+7fFMzi9Sp19+dmBlyYsd57/vPH4V9i5DWeOLOKeVhN78YDXwvCwxBAl luKMREMt5qLiRAB1R6z7aAIAAA== Cc: CLUE Subject: Re: [clue] Thoughts on issues #12/#13 - what goes in SDP? 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, 31 Aug 2012 19:17:09 -0000 Hi, >> I don't think CLUE signalling will be used only for adv/conf. I guess we= may also use it for certain types of indications - perhaps even some type = of controlling messages. > > I suppose that's possible, though AFAIK nothing of that sort has yet > been proposed. But it's irrelevant to the point I was making, which is > about which info should go in Adv/Conf and which should go in SDP. We also need to decide whether we put ANY requirements (when it comes to su= pport of protocol extensions etc) on non-CLUE devices, in order to be able = to interwork with CLUE systems. That will also impact what-do-we-transport-= where decisions. Regards, Christer ________________________________________ > From: clue-bounces@ietf.org [clue-bounces@ietf.org] On Behalf Of Paul Kyz= ivat [pkyzivat@alum.mit.edu] > Sent: Friday, August 31, 2012 12:51 AM > To: CLUE > Subject: [clue] Thoughts on issues #12/#13 - what goes in SDP? > > (As individual) > > Issues 12 & 13 ask how we separate what data should be carried in SDP > vs. what should be in clue-specific signaling. I've been thinking about > that, and while I don't have any answers I do have some thoughts to > share that might help decide this. > > One difference between the SDP and the CLUE-specific signaling is that > the SDP is governed by the O/A mechanism, while the clue signaling is > governed by the Advertisement/Configuration mechanism. Of course we can > change the mechanism for the clue signaling if we want, but for the time > being I'll assume we leave that mechanism as-is. > > There must be a coupling between the two. At the very least, before > transmission can begin in response to a new configuration message, the > negotiated SDP must be sufficient to support that. If the SDP in effect > *before* sending that configuration is not sufficient, then a new O/A > will need to be performed, and transmission according to the new > configuration can't begin until that O/A is complete. > > One approach to this would be to require an advertiser to constrain what > it advertises to things that are covered by currently negotiated SDP. > This then ensures that any configurations selected from that > advertisement can be done without another O/A. But it may also require > SDP demanding more resources (e.g. bandwidth) than will be required in > practice. > > Another approach would be to defer any needed adjustments to SDP until a > configuration is received by the advertiser. It could then initiate any > SDP changes needed to support that configuration. This allows the SDP > configuration to be tuned to what is needed for the particular > configuration. A downside is that if the O/A then fails, what should happ= en? > > Those are extremes. Between them are possibilities to do adjustments > from the receiving end before sending the configuration, and probably > other ways. > > Which approach is taken seems likely to profoundly impact the decision > about what which information can be in the SDP rather than the clue > messages. > > This gets more complex when you consider that advertisements and > configurations are flowing in both directions. If we aren't careful we > may end up needing an O/A exchange for each advertisement or > configuration. (But maybe this doesn't matter.) > > At the very least, it's important that it be clear which side is > responsible for initiating an O/A required by any clue message. > > Thanks, > Paul > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue >= From pkyzivat@alum.mit.edu Fri Aug 31 13:33: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 A12DD21F8577 for ; Fri, 31 Aug 2012 13:33:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.142 X-Spam-Level: X-Spam-Status: No, score=-1.142 tagged_above=-999 required=5 tests=[AWL=-0.705, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UbVNdPOdLD7K for ; Fri, 31 Aug 2012 13:33:32 -0700 (PDT) Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:24]) by ietfa.amsl.com (Postfix) with ESMTP id 97EFB21F8575 for ; Fri, 31 Aug 2012 13:33:32 -0700 (PDT) Received: from omta01.westchester.pa.mail.comcast.net ([76.96.62.11]) by qmta02.westchester.pa.mail.comcast.net with comcast id tNVG1j0030EZKEL51YZc6C; Fri, 31 Aug 2012 20:33:36 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta01.westchester.pa.mail.comcast.net with comcast id tYZq1j00B3ZTu2S3MYZqZ9; Fri, 31 Aug 2012 20:33:50 +0000 Message-ID: <50411F9B.3040103@alum.mit.edu> Date: Fri, 31 Aug 2012 16:33:31 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: Christer Holmberg References: <503FE07A.70609@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05853409FF2F66@ESESSCMS0356.eemea.ericsson.se>, <5040FE1A.1060700@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05853409FF2F6C@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05853409FF2F6C@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: CLUE Subject: [clue] Requirements on non-clue endpoints connecting to clue endpoints 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, 31 Aug 2012 20:33:33 -0000 On 8/31/12 3:14 PM, Christer Holmberg wrote: > Hi, > >>> I don't think CLUE signalling will be used only for adv/conf. I guess we may also use it for certain types of indications - perhaps even some type of controlling messages. >> >> I suppose that's possible, though AFAIK nothing of that sort has yet >> been proposed. But it's irrelevant to the point I was making, which is >> about which info should go in Adv/Conf and which should go in SDP. > > We also need to decide whether we put ANY requirements (when it comes to support of protocol extensions etc) on non-CLUE devices, in order to be able to interwork with CLUE systems. That will also impact what-do-we-transport-where decisions. That is also something that is distinct from resolving these two issues. So I've changed the subject. IMO the only requirements a non-clue endpoint need meet are: - support 3261 - support SDP, including ignoring unknown a-lines and rejecting m-line media types it doesn't support - support at least one audio and/or video m-line - have some codec in common with the other end That should be enough to get an initial session established. Then the clue endpoint can cope. Thanks, Paul > Regards, > > Christer > > ________________________________________ >> From: clue-bounces@ietf.org [clue-bounces@ietf.org] On Behalf Of Paul Kyzivat [pkyzivat@alum.mit.edu] >> Sent: Friday, August 31, 2012 12:51 AM >> To: CLUE >> Subject: [clue] Thoughts on issues #12/#13 - what goes in SDP? >> >> (As individual) >> >> Issues 12 & 13 ask how we separate what data should be carried in SDP >> vs. what should be in clue-specific signaling. I've been thinking about >> that, and while I don't have any answers I do have some thoughts to >> share that might help decide this. >> >> One difference between the SDP and the CLUE-specific signaling is that >> the SDP is governed by the O/A mechanism, while the clue signaling is >> governed by the Advertisement/Configuration mechanism. Of course we can >> change the mechanism for the clue signaling if we want, but for the time >> being I'll assume we leave that mechanism as-is. >> >> There must be a coupling between the two. At the very least, before >> transmission can begin in response to a new configuration message, the >> negotiated SDP must be sufficient to support that. If the SDP in effect >> *before* sending that configuration is not sufficient, then a new O/A >> will need to be performed, and transmission according to the new >> configuration can't begin until that O/A is complete. >> >> One approach to this would be to require an advertiser to constrain what >> it advertises to things that are covered by currently negotiated SDP. >> This then ensures that any configurations selected from that >> advertisement can be done without another O/A. But it may also require >> SDP demanding more resources (e.g. bandwidth) than will be required in >> practice. >> >> Another approach would be to defer any needed adjustments to SDP until a >> configuration is received by the advertiser. It could then initiate any >> SDP changes needed to support that configuration. This allows the SDP >> configuration to be tuned to what is needed for the particular >> configuration. A downside is that if the O/A then fails, what should happen? >> >> Those are extremes. Between them are possibilities to do adjustments >> from the receiving end before sending the configuration, and probably >> other ways. >> >> Which approach is taken seems likely to profoundly impact the decision >> about what which information can be in the SDP rather than the clue >> messages. >> >> This gets more complex when you consider that advertisements and >> configurations are flowing in both directions. If we aren't careful we >> may end up needing an O/A exchange for each advertisement or >> configuration. (But maybe this doesn't matter.) >> >> At the very least, it's important that it be clear which side is >> responsible for initiating an O/A required by any clue message. >> >> Thanks, >> Paul >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >>